N层架构

cod*_*dey 6 wcf entity-framework inversion-of-control n-layer

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

关于项目的快速信息:它是一个以数据为中心的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进行异常处理和日志记录

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

tom*_*ern 6

我建议以下评论:从一开始你的方法将产生紧密耦合.这直接违背了你的要求#3"松散耦合"

在您的图表中,您已定义了两个模块.主模块和模块2.我猜这两个模块彼此完全不同.我的意思是你可以完全单独开发它们然后插入它们,因为它们解决的业务问题是不同的.

但是,您当前的架构方法:

  • 将主模块和模块2数据耦合到同一数据库中
  • 将主模块和模块2业务对象耦合到同一业务层中
  • Couples主模块和模块2服务到同一服务层
  • 结合主模块和模块2的部署和管理

值得考虑的是:将主模块和模块2构建为单独的垂直服务堆栈.

我的意思是主模块和模块2成为主要服务服务2

每个服务都有自己的数据库,它自己的业务层,它自己的服务层和它自己的UI组件.

然而,这引起了关注:主服务和服务2如何协同工作来创建我的产品?

要解决这个问题:

  1. 在UI端,通过使用客户端代码将主服务和服务2的响应加载到一个视图中,将前端拼接在一起.

  2. 在后端,您使用发布订阅消息传递来允许主服务订阅服务2中发生的事件,反之亦然.

这将导致应用程序在松散耦合的垂直服务堆栈之上构建一个应用程序,通过异步交换消息来保持一致性.

如果您需要在应用程序中添加新模块,则可以创建一个新的服务堆栈,该堆栈支持所需的功能并将其连接起来,而其他堆栈几乎不需要更改(理想情况下是更改现有堆​​栈的唯一原因)将是他们想要订阅新模块中的事件).

这是一个与你建议的方法截然不同的方法,但是在我的意见中,它可以让你更好地满足松散耦合的要求.

  • 我的主要观点是这一点.为什么计划将各种功能组合到一个应用程序中?如果您的应用程序的两个部分垂直不同,那么它们应作为单独的问题进行规划,开发,部署和管理. (3认同)

Joe*_*zer 1

WPF、WinForm 等 UI 应该调用 WCF 层,这是有道理的。我假设拥有多个 UI 是一种业务需求,否则,如果您只能拥有一个 UI,那么响应式 Web UI 是最灵活的选择。

但是,我不认为您的 MVC UI 需要使用 WCF 层。它可以直接调用领域层。这样会更快并删除无意义的层。

显然,只有当您不在 WCF 层中放置任何逻辑时,这才有效。WCF 层中确实不应该有任何逻辑。

您还声明希望将 IoC 和 DI 放置在分布式服务层中。这对于 MVC UI 来说没有多大意义。您需要在 MVC 项目中使用 DI,以便可以对控制器进行单元测试。