cod*_*dey 6 wcf entity-framework inversion-of-control n-layer
我遇到的情况是我必须从头开始设计和实现一个系统.我对架构有一些疑问,我希望你的评论和想法.
关于项目的快速信息:它是一个以数据为中心的Web应用程序.
该应用程序将构建在带有MS SQL SERVER 2008数据库的Microsoft .NET Framework 4.0上.
需求:
下面是我构建的架构图:

建筑简报
我的担忧:
寻找有价值的意见和建议.如果我做错了什么,请把我指向正确的方向.
我建议以下评论:从一开始你的方法将产生紧密耦合.这直接违背了你的要求#3"松散耦合"
在您的图表中,您已定义了两个模块.主模块和模块2.我猜这两个模块彼此完全不同.我的意思是你可以完全单独开发它们然后插入它们,因为它们解决的业务问题是不同的.
但是,您当前的架构方法:
值得考虑的是:将主模块和模块2构建为单独的垂直服务堆栈.
我的意思是主模块和模块2成为主要服务和服务2
每个服务都有自己的数据库,它自己的业务层,它自己的服务层和它自己的UI组件.
然而,这引起了关注:主服务和服务2如何协同工作来创建我的产品?
要解决这个问题:
在UI端,通过使用客户端代码将主服务和服务2的响应加载到一个视图中,将前端拼接在一起.
在后端,您使用发布订阅消息传递来允许主服务订阅服务2中发生的事件,反之亦然.
这将导致应用程序在松散耦合的垂直服务堆栈之上构建一个应用程序,通过异步交换消息来保持一致性.
如果您需要在应用程序中添加新模块,则可以创建一个新的服务堆栈,该堆栈支持所需的功能并将其连接起来,而其他堆栈几乎不需要更改(理想情况下是更改现有堆栈的唯一原因)将是他们想要订阅新模块中的事件).
这是一个与你建议的方法截然不同的方法,但是在我的意见中,它可以让你更好地满足松散耦合的要求.
WPF、WinForm 等 UI 应该调用 WCF 层,这是有道理的。我假设拥有多个 UI 是一种业务需求,否则,如果您只能拥有一个 UI,那么响应式 Web UI 是最灵活的选择。
但是,我不认为您的 MVC UI 需要使用 WCF 层。它可以直接调用领域层。这样会更快并删除无意义的层。
显然,只有当您不在 WCF 层中放置任何逻辑时,这才有效。WCF 层中确实不应该有任何逻辑。
您还声明希望将 IoC 和 DI 放置在分布式服务层中。这对于 MVC UI 来说没有多大意义。您需要在 MVC 项目中使用 DI,以便可以对控制器进行单元测试。
| 归档时间: |
|
| 查看次数: |
4543 次 |
| 最近记录: |