MVC + WCF：架构设计决策

Question

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

以下是依赖关系图，用于了解事物的结构：

有几点需要注意：

• Common MyApp.Utilities项目适用于需要跨层共享的任何功能。目前它只包含扩展方法。
• 服务合同和数据合同属于一个共同的项目，在两个层之间共享。
• EntityFramework正用于数据访问。
• 映射进入实体＆lt; =＆gt; DTO（数据合同）＆lt; =＆gt;视图模型
  • 仍在使用AutoMapper，并不完全确定我应该如何＆＃34;补水＆＃34; DTO从表示层传回时。
• ServiceImplementation只是业务逻辑的包装器，它包含在一个单独的程序集中。
• 将演示文稿和服务层部署到单独的物理服务器
• 软件包全部包含在解决方案的根文件夹中的单个文件夹中，并且已签入版本控制

这些都是不好的做法吗？

Answer 1

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

我会避免这种情况。它似乎是额外的工作，但我会将它们分解为单独的命名空间和类，即使它导致重复。我通常回避计划不可预见的事情，但是，我从来没有一个项目，我的所有数据合同都与我的所有服务合同一致。适应差异​​的黑客往往会导致令人困惑的反模式。

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

Answer 2

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

• 数据合同（实体框架）不属于共同项目;
• 我们正在使用当前的AutoMapper来映射实体框架模型和服务模型（简单和复杂类型）之间 服务模型和视图模型。
• 我们在DAC，服务层和表示层中实现接口实现，以使用依赖注入（我们使用Ninject）来实现 使层更多＆＃34;可测试＆＃34;，所以我们也有所有这些合同 层。
• 演示文稿基本上是使用安静方法的Web Api。

效果很好，我的体系结构中没有任何问题。