ASP.NET MVC应用程序体系结构“准则”

我正在寻找一些关于我的基于ASP.NET MVC的CMS应用程序体系结构的反馈。ASP.NET MVC应用程序体系结构“准则”

域模型 - 仅依赖于System类来定义类型。目前，主要是贫血。

库层 - 抽象的数据访问，只由服务层

服务层称为 - 在域模型执行业务逻辑。将视图模型公开给控制器。

ViewModelMapper - 服务，翻译来回的视图模型和领域模型之间

控制器 - 超薄“交通警察”的风格，与服务层，只有在视图模型，从未领域模型方面的谈判交互功能

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

服务层有点棘手......我只希望控制器能够访问视图模型以简化GUI编程。但是，一些服务需要彼此交谈。例如，我有一个事件服务，在标记内容，创建博客文章等时通知其他监听器服务。目前，将域模型作为输入或返回它们的方法标记为内部，因此它们不能被控制器。

听起来像矫枉过正？没有足够的抽象？我主要是在严格的架构上进行学习，而不是针对实际的产品，所以请不要在“正确取决于你想做什么”的方向上反馈意见。

谢谢！

来源

2010-04-04 Jason Barile

事实上，你用这么几句话说了这么多话应该会让你知道你正处在正确的轨道上。 – pdr 2010-04-04 15:03:50

总的来说，设计看起来不错。

还有数个项目我可能会做：

验证 - 有一个2步验证 -
步骤1：将域级类执行自己的有效性（通过属性或任何其他机制）。
步骤2：存储库确保该对象在存储库上下文中有效
依赖注入 - 使用DI框架注入依赖关系。这对单元测试很有用。此外，如果服务层，在那里，你需要通过服务调用，检查如果这篇文章对聚合服务是非常有用的：http://blog.ploeh.dk/2010/02/02/RefactoringToAggregateServices.aspx
- 的ViewModels - 可能是很有诱惑力的再利用，但等待&手表，你终于决定

HTH。

来源

2010-04-04 14:50:54 Sunny

很好的答案。在过去，我们过去称为步骤1“验证”和步骤2“验证”。 – pdr 2010-04-04 15:01:54

谢谢Sunny。我实际上使用了StructureMap for DI，所以我很好。目前，为了验证，我有一个验证服务来验证域模型。我喜欢让模型阻止自己进入无效状态，我认为我更喜欢在域模型中嵌入“有效状态”类型的业务规则。你在哪里在领域模型和其他地方（验证服务，存储库等）的规则之间画线？ – 2010-04-04 16:55:57

为了让我的域模型保持有效状态，我不在模型上放置任何属性设置器。相反，所有状态更改都必须通过一种方法，在应用之前验证更改是否合适。缺点是，如果你有很多潜在的变化，这可以成为相当数量的代码。创建和删除操作仍在存储库层上。 – Ryan 2010-04-04 17:17:02

ASP.NET MVC应用程序体系结构“准则”

回答

相关问题