MVC + WCF：架构设计决策答案

【问题标题】：MVC + WCF: Architecture Design DecisionsMVC + WCF：架构设计决策
【发布时间】：2016-10-12 20:23:02
【问题描述】：

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

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

需要注意的几点：

Common MyApp.Utilities 项目适用于需要跨层共享的任何功能。目前它只包含扩展方法。
服务合同和数据合同在两个层之间共享的共同项目中。
EntityFramework 正在用于数据访问。
映射进入实体 DTO（数据合同） ViewModel
- 仍在处理此问题，使用 AutoMapper，但不完全确定在 DTO 从表示层传回时我应该如何“重新水化”它们。
ServiceImplementation 只是一个包含在单独程序集中的业务逻辑的包装器。
表示层和服务层将部署到单独的物理服务器上
包都包含在解决方案根文件夹的单个文件夹中，并已签入版本控制

这有什么不好的做法吗？

【问题讨论】：

这个高层次的设计看起来不错 - 但魔鬼在细节中，而且它在很大程度上取决于特定的工作领域。对“通用” dll 非常小心 - 他们倾向于变成“我不知道在哪里或设计不支持 bin 的所有内容”。 IMO 最重要的是遵循 SOLID 并非常强调依赖注入 - 我认为从项目的长期（和短期）来看，这将是好代码与非好代码之间的区别

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

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

效果很好，我在您的架构中看不到任何问题。

【讨论】：

从我的角度来看关于依赖注入的注释 - 虽然它使代码的可测试性提高了 100 倍，但我认为主要的好处是当需求更改/添加时，您只需要添加一些新类就可以了所有“神奇地”都很好地结合在一起（至少只要最初的设计是好的）
@GiladGreen 你是对的，这是 DI 的另一大好处。