asp.net-mvc - ASP.NET MVC 应用程序架构 "guidelines"

Question

我正在寻找一些关于我的基于 ASP.NET MVC 的 CMS 应用程序架构的反馈。

域模型——只依赖于系统类来定义类型。目前，主要是贫血。

Repository Layer - 抽象的数据访问，仅由服务层调用

服务层 - 在域模型上执行业务逻辑。向 Controller 公开 View 模型。

ViewModelMapper - 在 View 模型和域模型之间来回转换的服务

Controller - 超薄的“交通警察”风格的功能，与服务层交互并且仅根据 View 模型进行对话，而不是域模型

我的域模型主要用作数据传输 (DTO) 对象，目前具有最少的逻辑。我发现这很好，因为它不依赖任何东西(甚至不依赖于服务层中的类)。

服务层有点棘手......我只希望 Controller 能够访问 View 模型以便于 GUI 编程。但是，某些服务需要相互通信。例如，我有一个事件服务，它在标记内容、创建博客文章等时通知其他监听器服务。目前，将域模型作为输入或返回它们的方法被标记为内部，因此它们不能被使用 Controller 。

听起来有点矫枉过正？不够抽象？我这样做主要是作为对架构严格的学习练习，而不是针对实际产品，因此请不要反馈“正确取决于您想做什么”。

谢谢!

Answer 1

总的来说，这个设计对我来说看起来不错。

还有一些我可能会做的事情:

验证 - 有两步验证 -
第 1 步:域级类强制执行它们自己的有效性(通过属性或任何其他机制)。
第 2 步:存储库确保对象在存储库的上下文中有效

依赖注入(inject) - 使用 DI 框架注入(inject)依赖。这对单元测试很有用。另外，如果需要跨服务调用的服务层，请查看聚合服务这篇文章是否有用:http://blog.ploeh.dk/2010/02/02/RefactoringToAggregateServices.aspx

ViewModels - 可能很想重复使用，但在你最终决定之前等待并观察

HTH。