当我第一次听说ASP.NET MVC时,我认为这意味着应用程序有三个部分:模型,视图和控制器.
然后我读了NerdDinner并了解了存储库和视图模型的方法.接下来,我阅读了this tutorial,很快就出售了服务层的优点.最后,我阅读了Fluent Validation documentation,如果我最终没有写出一堆验证器,我会很高兴.
今晚,我退后一步,想一想我的项目是什么.它似乎已成为相当于“特征蠕变”的设计模式的受害者.不知何故,我从Model-View-Controller转到Model-Repository-Service-Validator-View-viewmodel-Controller.你想要松散耦合和DRY?我们把你的松散耦合和DRY放在这里!但我想知道这是不是一件好事.
我是对的吗?或者这实际上并不像听起来那么疯狂?一方面,拥有这么多层似乎很疯狂.另一方面,每一层都有一个明确定义的目的,对我来说是有意义的.您的MVC应用程序也变成了MRSVVVMC应用程序吗?如果没有,它们看起来像什么?哪个是正确的平衡?
解决方法
如果您有一个具有三个属性的表单,则这是过度的.
但是如果你有一个“真正的”应用程序,并且每个层的职责都已明确定义,我认为这是非常合理的.