C# MVC&x2B；WCF&x2B；TDD或DDD体系结构

我们又到了十字路口

我希望至少在未来3年内，尝试实现一种简单、经验证的方法来构建我的应用程序。 每次我要开始一个项目的时候，我都觉得这是第一次，因为现在创建网站的“方法”太多了

我从我购买的call Design Pattern Framework 4 C#软件包中得到了这个示例代码。在他们拥有的多个项目中，有一个叫做设计模式（designpatterns）。你可以从这里下载

我的问题是，在你看了这个解决方案之后，关于这个例子，什么是好的，什么是坏的，你会保留什么，你会删除什么，什么是不必要的，等等

我知道他们试图显示多个客户端和多个DAO。但总的来说，这个体系结构会被你当作一个“模板”吗？

---

谢谢。

系统架构与建筑架构非常相似：

• 没有一条“正确”的道路
• 每个人对“最好的”都有自己的看法
• “最佳”架构取决于上下文和需求
• 风格和方法会随着时间的推移而改变

选择体系结构时有许多因素：

• 上市时间-你需要多长时间才能让产品上市
• 可维护性-您是唯一维护它的人吗？开源
• 可扩展性-它是封闭系统还是开放系统
• 可扩展性-简单实用程序还是企业规模
• 平台-网络还是本机？台式机还是手机

所有这些都表明，如果你能提出一个适合未来3年所有项目的全方位整合框架，我会感到惊讶。将MVC、WFC、TDD、DDD等视为工具，您可以使用这些工具构建正确的系统，以满足这种情况的需要

我的观点是：使用任何你能理解的概念（必要时可以教别人），只要它适合特定的情况

选择一个

试试看

如果不适合您，则重构/更改 最重要的是，确保使用可重构的模式。如果您正在使用TDD，并且发现可以注入依赖项、伪项等，那么这将简化重构过程。三年是一个很长的时间来使用任何给定的模式。一位朋友说，如果你不看6个月前的代码，觉得它很糟糕，那么你可能学的还不够：）

我的问题是，在你看了这个解决方案之后，什么是好的，什么是坏的， 你会保留什么，你会删除什么，什么是不必要的，等等 等等，关于这个例子

快速浏览之后，我想说：

• 关于您问题中的DDD标签，这显然不是一个域驱动的体系结构。业务对象与一些简单的验证规则不同，DDD体系结构的许多基本构建块都不存在（聚合、值对象等）

• 除非我遗漏了什么，否则大多数业务操作都是CRUD操作，它并不能真正代表真实世界的企业应用程序

• 有一个fat服务层和一个fat ActionService类，它基本上似乎处理应用程序的所有用例。好消息是，它以不可知的方式处理用例（据我所知，它处理的请求和响应对象是独立于交付机制的）。肥胖是不可取的，因为这门课包含了太多的责任（）

• 在客户端使用存储库，在服务器端使用DAO似乎很奇怪，但为什么不呢

• 如果它真的是测试驱动的，为什么不包括所有的单元测试而不是一个样本呢

---

除此之外，这些层设计得很好，正如多个表示层所显示的那样，用一个前端替换另一个前端或者用一个持久存储替换另一个并不困难。

对此，您可能得到的唯一答案是“我认为XYZ很好，因为我使用它”没有神奇的子弹，一刀切的治疗方法。你可以使用任何能让你最有效率的东西。系统架构更好，因为我们可以进去改变我们的建筑：）我理解你的观点。我试图在web应用程序中涉及的所有元素之间取得平衡。我想最让我困惑的是你在那里发现了大量的“最佳实践”。事实是，很多时候他们自相矛盾。我正试图使用上述解决方案为自己设置一个“工作模板”，因为我所有的应用程序的结构基本相同。谢谢你的回答。正如@d_stanley所说，MVC、WCF、TDD和DDD都是工具、框架、方法、最佳实践的集合等等。TDD的狂热会使一个项目瘫痪，如果你不折不扣地遵循它，类似DDD的设计模式是一个你可以选择的工具包（你不应该在每个项目中都使用它）。MVC和WCF都是非常时髦的框架，它们分别使创建/处理网站和通信变得更加容易，而且在各个方面都是不错的选择。这正是我想要做的：不要陷入编码的“完美主义”一面。我发现这段代码，看起来非常健壮，也有点通用，但至少它让您了解了许多“正确”做事的方法之一。谢谢您的回答。这不是一个好主意“充分应用。我想他们想展示不同的模式是如何协同工作的，等等。读了一点关于DDD的内容后，我意识到它与DDD无关。我认为他们在客户机上拥有存储库的原因是为了能够对其进行统一测试。文件上就是这么说的。事实上，此示例还附带了一个windows表单示例wpf、webforms（mvp）。但我删除了它，因为