标签: n-layer

我正在考虑在我的新项目中使用MVC模式,我可以清楚地看到能够将数据层(模型)更接近表示层(视图)的主要优势,这将允许稍微增加在申请速度.但除了性能观点之外,MVC还是在视图 - 逻辑 - 数据分层类型模式上还有其他优势吗？

编辑: 对于那些感兴趣的人我刚刚上传了我创建的示例PHP代码来测试MVC的使用.我故意省略所有安全检查以使代码更容易阅读.请不要过多批评它,因为我知道它可以更加精致和先进,但不过 - 它有效!我将欢迎提出问题和建议:链接如下:http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip

事先有一件事:我从N层背景到达.

我现在花了很多时间来了解洋葱建筑和相关的领域驱动概念,如六角建筑阅读资源,如Jeff Palermo的系列博客文章,Mark Seemann从DI视角的贡献,"洋葱化你的建筑",和"干净的建筑".

所有这些文章的共同之处在于它们声称有以下几点:

• 焦点围绕业务用例的域模型
• 通过强调依赖性倒置原则,在层之间进行更松散的耦合
• 提高外部基础架构的独立性,例如框架,数据持久性,UI
• 更好的可测试性/可维护性

嗯,这听起来非常好听,那些图表看起来也很甜美.但是问题出现在我身上:仅仅通过在传统的N层架构中增加外墙来实现这一切吗？

• 每个层只知道下面层的抽象
• 具体实现可以保持在每个层的内部,因此与抽象处于相同的位置
• 实现细节可以很容易地换出,因为它们是层的内部,不应该影响应用程序的其余部分

请帮助我了解以域为中心的架构的真正优势.

提前致谢!

在花了几个月研究DDD方法之后,我现在开始将这些概念应用到我公司的实际产品中.事实上,我的任务是为未来的开发创建一个合适的,可维护的架构.

我们决定使用以下技术:EF4(真正的v2),Unity

我获得的信息量最具启发性,但是,我在最佳实践中留下了几个问题:

问题#1: DTO - 最佳实践

我有我的域对象(PO​​CO类).有几种方法可以实现这些类.

1. 传统方法:创建包含公共getter/setter,Validation和适当业务逻辑的POCO类.还要创建DTO并使用映射技术来管理它们.(Automapper)
2. 传统 - DTO:创建如上所述的POCO类,但是,使用您的POCO作为传输对象.我的理解是业务对象永远不应该离开域.
3. 混合:我偶然发现了一篇有趣的博客文章,其中作者创建了他的POCO对象和DTO.在他的域对象内部,他创建了一个DTO实例.这样可以更轻松地维护,因为您不会像#1那样复制属性.像这样:

public abstract class POCOBase<T> : ValidationBase, IPOCO where T : DTOBase, new()
{

 public T Data { get; set; }

 public POCOBase()
 {
     Data = new T();
 }

 public POCOBase(T dto)
 {
     Data = dto;
 }
  }

  public class SomePOCO : POCOBase { }

  public class SomeDTO : DTOBase

  {

 public String Name { get; set; }

 public String Description { get; set; }

 public …

所以我的asp.net非常生疏,我正在努力重新回到最佳实践中.所以,我掏出google并开始寻找示例,示例和教程,但我能找到什么？即使在"最新"技术出现之前,往往会在石器时代发布的旧硬壳.

当然,这些概念可能仍然存在.但实际的实现基本上没用.我正在寻找使用Linq的东西,n层(不是层.层可以是层,但层不一定是层)某种当前的ORM(L2S,EF等)和一些现实世界东西,不是abitrary和无用的例子.

有没有人有任何指针？

我有一些关于整体和n层架构的问题.

首先,Monolith和n Layer架构之间的区别是什么？

其次,假设我有一个Visual Studio解决方案,它包含多个项目,例如:

1. 表达层
2. 服务层
3. 业务层
4. 交叉层
5. 数据层
6. 单元测试

那被认为是Monolith还是n层架构？

如果我有微服务(包括说)3 Web API并且我在单独的Visual Studio解决方案中构建每个服务,那么可以实现我以前的项目结构(服务层,业务层,数据层等)吗？

非常感谢你,抱歉我的英语不好.

我正在使用ASP.NET Web表单C#从头开始创建解决方案.

我担心模型对象,因为我不想在每个层中创建重复的模型对象集.在3层体系结构中使用Model对象的最佳实践是什么Web Forms？

我想到的结构如下:

• UI
• BLL
• DAL
• 模型

模型将包含可在层的每个部分中使用的所有模型类.我认为这将是有用的,因为每个层都需要访问模型对象.例如:

1. UI调用BLL中的方法传递填充数据的模型对象.
2. BLL调用DAL中的方法传递保存在数据库中的对象等.

谢谢

所以,我在这里查看了一些关于规范模式的帖子,但还没有找到答案.

我的问题是,在一个n层架构中,我应该在哪些规范中获得"新建"？

1. 我可以将它们放在我的服务层(也就是说,应用层,它有时被称为......基本上,.aspx代码隐藏的东西会与之交谈),但我觉得通过这样做,我让业务规则漏掉了域名.如果以其他方式(除了服务层)访问域对象,则域对象无法强制执行自己的业务规则.

2. 我可以通过构造函数注入将规范注入到我的Model类中.但同样,这感觉"错误".我觉得唯一应该注入Model类的是"服务",比如缓存,日志记录,脏标记跟踪等等......如果你能避免它,那么使用Aspects而不是乱丢模型的构造函数具有大量服务接口的类.

3. 我可以通过方法注入(有时称为"Double Dispatch")注入规范,并明确地使用该方法封装注入的规范以强制执行其业务规则.

4. 创建一个"域服务"类,它将通过构造函数注入获取规范,然后让服务层使用域服务来协调Domain对象.这对我来说似乎没问题,因为规范强制执行的规则仍然在"域"中,而Domain Service类的命名方式与它正在协调的Domain对象非常相似.这里的事情是我觉得我正在编写大量的类和代码,只是为了"正确"实现规范模式.

除此之外,相关规范要求存储库以确定它是否"满意".

这可能会导致性能问题,尤其是 如果我使用构造函数注入b/c消耗代码可以调用一个可能包装规范的属性,并且反过来调用数据库.

所以任何想法/想法/链接到文章？

新产品和使用规格的最佳位置在哪里？

我遇到的情况是我必须从头开始设计和实现一个系统.我对架构有一些疑问,我希望你的评论和想法.

关于项目的快速信息:它是一个以数据为中心的Web应用程序.

该应用程序将构建在带有MS SQL SERVER 2008数据库的Microsoft .NET Framework 4.0上.

需求:

1. 丰富的UI和强大
2. 多设备支持(每个浏览器和每个设备)
3. 松散耦合

下面是我构建的架构图:

建筑简报

1. 表示层:HTML5/ASP.NET MVC + JQuery(第一版中支持多设备的Web应用程序)
2. 分布式服务:WCF(XML/JSON/JSONP)
3. 域层(业务层):所有业务逻辑
4. 数据持久性(DAL层):具有数据库第一种方法的实体框架4.0.使用T4模板生成并分离出POCO实体
5. 基础结构层:包含常见的库,如POCO实体,异常处理,日志记录等

我的担忧:

1. 由于应用程序要松散耦合,因此将来如果业务需求增长,可以轻松插入新模块而不会影响架构.所以我想到使用Repository模式以及IoC和DI(可以是Unity/Ninject/Sprint.NET或任何其他)
2. 支持XML和JSON的WCF
3. 分布式服务层,用于放置IoC和DI
4. 使用Enterprise Library 5.0进行异常处理和日志记录

寻找有价值的意见和建议.如果我做错了什么,请把我指向正确的方向.

Alistair Cockburn介绍了一种六角形架构,现在它被称为端口和适配器模式.在我的理解中,这个概念类似于n层架构,其中一层仅通过抽象(接口)依赖于另一层.例如,应用程序层依赖于许多存储库服务接口而不是它的实现.这里不需要单独实现端口或适配器.像Unity这样的IoC容器可以注入存储库的实现,因此不需要适配器.

我是否将此端口和适配器模式与DIP(依赖注入原则)混淆？

有人能指出我的端口和适配器模式的实现？谢谢.

任何人都可以使用依赖倒置来解释洋葱架构和分层架构之间的区别吗？他们在我看来完全一样。非常感谢任何输入:)