MVC + WCF：体系结构设计决策

Question

我目前正在研究一个项目，该项目由一个ASP.NET MVC Web应用程序和一个后端包装在WCF服务中组成。 我在过去的项目中使用过MVC和WCF，但我从未负责过从头开始设计架构。 我希望对我当前的设计有一些反馈，以确保我从高层架构的角度采用良好的设计实践。

以下是依赖关系图，可让您了解事物的结构：

注意事项：

• Common MyApp.Utilities项目适用于需要跨层共享的任何功能。 当前，它仅包含扩展方法。
• 服务合同和数据合同在一个公共项目中，在两个层之间共享。
• EntityFramework用于数据访问。
• 映射进入实体<=> DTO（数据协定）<=> ViewModel
  • 仍在使用AutoMapper进行此操作，并且不确定将DTO从表示层传递回时应如何“补水”。
• ServiceImplementation只是业务逻辑的包装，包含在单独的程序集中。
• 表示层和服务层将部署到单独的物理服务器
• 软件包全部包含在解决方案的根文件夹中的一个文件夹中，并签入版本控制

这有什么不好的做法吗？

Answer 1

•服务合同和数据合同在一个公共项目中，在两个层之间共享。

我会避免这种情况。 这似乎是多余的工作，但是即使将导致重复，我也会将它们分解为单独的命名空间和类。 我通常会避开不可预见的计划，但是，我从未有过一个项目，其中我的所有数据合同与我的所有服务合同保持一致。 适应差异​​的技巧往往会导致反模式混乱。

这些类中的大多数将具有相同的属性，并且可以使用自动映射器轻松地对其进行映射。

Answer 2

您上面提出的架构与我在项目中使用的架构非常相似。 一些评论：

• 数据合同（实体框架）不在同一个项目中；
• 我们目前正在使用AutoMapper在实体框架模型和服务模型（简单和复杂类型）之间以及服务模型和视图模型之间进行映射。
• 我们在DAC，服务层和表示层中都有接口实现，以使用依赖项注入（我们使用Ninject）来使层更“可测试”，因此在所有这些层中也都有契约。
• 演示基本上是具有宁静方法的Web Api。

它运作良好，在您的架构中看不到任何问题。