当我第一次听说 ASP.NET MVC 时，我认为这意味着应用程序由三个部分组成:模型、 View 和 Controller 。
然后我读到 NerdDinner并学习了存储库和 View 模型的方法。接下来，我读到this tutorial并很快就被服务层的优点所吸引。最后，我读了Fluent Validation documentation ，如果我最终没有编写一堆验证器，那我就该死了。
今晚，我退后一步思考我的项目发生了什么。它似乎已经成为相当于“功能蔓延”的设计模式的受害者。不知何故，我从模型- View - Controller 转到模型-存储库-服务-验证器- View - View 模型- Controller 。您想要松散耦合且 DRY 吗？我们在这里得到了您的松散耦合和干燥!但我想知道这是否是一件好事太多了。
我的担心有道理吗？或者这实际上并不像听起来那么疯狂？一方面，拥有这么多层似乎很疯狂。另一方面，每一层都有一个明确定义的目的，这对我来说是有意义的。您的 MVC 应用程序也变成了 MRSVVVMC 应用程序吗？如果不是，它们是什么样子的？正确的平衡在哪里？
最佳答案
如果你的一种形态具有三种属性，那就太过分了。
但是如果您有一个“真正的”应用程序，并且每一层的职责都定义良好，我认为这是相当合理的。
关于asp.net - 模型-存储库-服务-验证器- View - View 模型- Controller 设计模式(？)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2091991/