架构MVC Web项目/不同类型的模型

UI
核心（服务&模型，实用程序）
库（ LINQ2SQL）

依赖是

用户界面 - >核心
核心 - >存储库。

我想业务和模式是在自己的组件，并与同时围绕模型建立的东西最终，即：

UI - >模型，服务
服务 - >模型，库
库 - >模型
模型

钍我正在构建的e系统基本上是一个网站CMS，因此我将为网页（PageModel）建立一个模型，该网页包含子网页集合。 PageModel可以调用服务（PageService）中的方法来填充其子页面，但是在新设计中不可能发生，因为Models集合对服务程序集一定一无所知。

我已经考虑过在洋葱体系结构（即依赖注入）中的一些想法来解决这个问题，但似乎可以使用更优雅/明显的解决方案。

我是否需要引入另一层模型？查看模型？我认为我所说的模型是领域模型......我可能错了！服务将是域服务？

所以我的解决办法是：

UI - >服务，的ViewModels，模型
的ViewModels - >服务，模型
服务 - >存储库，模型
库 - >模型
模型

在这个例子中，我想像m y PageViewModel将扩展PageModel并使用PageService来获取它的子页面。

任何建议赞赏。还有关于这些模型通常被称为什么的指针？我在这里谈论的是DTO模型而不是域模型？和领域模型而不是视图模型？看起来我提议使用视图模型并不是视图模型的工作。

感谢

编辑：

这是我从来没有最初提到的是，我的领域模型是不是单一的数据库实体的基本翻译就像你会在大多数教程看到的。域模型可以包含来自多个相关数据库表的数据字段。

所以值得拥有一组模型纯粹是为了封装域中的数据 - 没有任何方法/属性来获取相关对象或将对象保存回数据库等？ - 数据传输对象。

从看一对潦草的图表，这将意味着在域图层中有一组映射器（这似乎是错误的）将DTO模型翻译为域模型并返回。该项目将围绕DTO模型而不是域模型构建，但给出了DTO封装的内容，我不认为这是一个问题。

任何人谁是有兴趣的，所提出的依赖结构会像这样：

UI - >服务，领域模型
服务 - >存储库，领域模型中，DTO模式
领域模型 - >库，DTO模型
映射器 - >域模型，模型DTO
库 - > DTO模型
DT O型号（无相关性）

这有点混乱！所有这一切都只是因为我希望我的PageModel能够获取自己的子页面模型。它看起来像是在依赖注入方面可能不是一个坏计划。

感谢那些已经回复的人。你给了我很多想法。

来源

2012-02-28 Giles

你可以用洋葱结构完成这一切。我得例如： UI，域名，数据访问，服务

UI 服务数据访问域（包含视图模型以及）

UI可以访问任何一个。服务，只有数据访问和域。数据访问 - 唯一域。

我的存储库接口位于域项目中，它们在数据访问项目中实现。我还在域项目中保留了其他接口（IContext，IUnitOfWork等），所以我有一个中心位置，而不是在项目之间传播太多的接口。

如果您认为合适，DTO将仅用于在图层之间进行转移。对于我来说没有理由你不能从数据层向上传递域模型，有些人选择在这里只使用DTO。因为我可以使用AoP为我做（[AutoMap（）]属性），所以我会在UI层（前MVC控制器）中执行映射到ViewModel。

只要记住您的模型不应该包含任何持久性逻辑。

来源

2012-02-28 21:41:37

谢谢亚当。将存储库接口放在域中似乎是一种以域为中心的一切方式的好方法。在持久性点上，我的域模型为Save（）提供了便捷的方法，它只是在相关存储库中调用Save（）方法。你会认为这是持久性逻辑，因此不好的做法？ – Giles 2012-02-28 22:44:25

雅，他们应该对此一无所知。将实体传递到您的存储库，并让它成为处理所有事情的单一位置。这可以很好地适应工作单元模式，因为存储库可以被重构为现在实际上将其保存到集合中，并且工作单元实现将该集合保存到一个事务中的数据库中。您的服务不是调用模型上的Save（），而是知道调用存储库实现，该实现应该注入到控制器或存储库中。这非常适合测试/嘲笑/等。 – 2012-02-28 22:59:57

我认为这是非常典型的任何“真实世界”的应用程序以不同的方式存储数据比显示在屏幕上的。我认为你是在正确的轨道上，拥有2个独立的“模型”。我通常最终打电话给他们：

ViewModels - 映射到屏幕上显示的内容，视图需要什么。
DataModels - 映射到数据库，什么持久层（ORM）希望。

有时作为数据访问层，或Data Transfer Objects（DTO的）谈论实体框架尤其是当DataModels称为Entities。

通常有一些组“翻译”从视图的数据模型映射的太，或有时可以使用AutoMapper。

当然，如果你正在显示足够接近你的数据结构，不存在损害正在通过所有持久/数据模型的意见，但我喜欢让他们分开了。

来源

2012-02-28 21:50:40 CodingWithSpike

谢谢。我开始怀疑DTO模型。我的模型不一定是来自单个数据库表的简单映射。我可能不得不回答我自己的帖子来解释，虽然.. – Giles 2012-02-28 22:50:46

我已经考虑过在洋葱体系结构（即依赖注入）中的一些想法来解决这个问题，但似乎可以使用更优雅/明显的解决方案。

一旦您正确使用依赖注入的悬念，它确实是一个非常优雅/明显的解决方案。

我建议一个依赖结构是这样的：

UI
- 控制器 - >服务，模型的ViewModels
- 视图 - >的ViewModels
- 的ViewModels（无依赖性）
服务 - >存储库，模型
库 - >模型
模型

这是非常接近你有什么之前，但你的ViewModels是你的UI项目的一部分，在都没有相关性。他们应该是简单的类，代表你想要展示给用户的东西。

这是控制器的工作是：

调用服务来获得模型，
翻译模型成的ViewModels和
调用视图代码

意见应不需要任何ViewModels不提供的信息。

来源

2012-02-28 22:06:47 StriplingWarrior

谢谢。我认为依赖注入开始看起来像要走的路。这个项目已经非常复杂了（虽然我的标准......）并且实施DI可能是一个相当大的挑战。 – Giles 2012-02-28 22:58:50

@Giles：DI有一种倾向，让你遵循良好的设计模式。由于您一直没有使用它，所以尝试使代码遵循它应该一直使用的模式可能会有一些痛苦。但如果你做得对，DI实际上应该可以帮助你简化一些事情。祝你好运。 – StriplingWarrior 2012-02-28 23:07:36

架构MVC Web项目/不同类型的模型

回答

相关问题