Question

您能否以与MVP设计模式匹配的方式对解决方案项目，文件和fodler进行构建，以表示模式理念？

我的意思是你如何放置你的演示者，数据访问层，视图等。

由于

Answer 1

解决方案体系结构通常非常独立于您正在使用的UI体系结构，尽管您可能有一些额外的分离如果您计划拥有多个UI应用程序（大多数项目没有）。

我倾向于从类似的模板开始：

Acme.Sales或Acme.Sales.Core - 内部域/业务逻辑
Acme.Sales.Entities - 用于持久层的数据实体。实体具有与核心（域）模型类似的类结构，但往往具有更薄的逻辑，诸如Id的附加属性，双向关系（与域模型中的单向关系相对），以及{ {1}} ORM的成员可以覆盖。此程序集通常还包括抽象存储库，用于实体上的CRUD操作。
virtual其中Acme.Sales.Entities.Impl类似Impl或LinqToSql - 此命名空间定义了实际持久化NHibernate的一种可能实现。 抽象存储库的具体实现在这里。
Entities包含与任何用户界面相关的公共类 - 可能是MVP GUI甚至是CLI。与Acme.Sales.UI一样，它们与Entities类类似，但往往具有特定于表示的逻辑和属性，例如验证和格式化（现在通常通过Core）。请注意，核心库应该也验证，但UI验证往往更多地是关于输入的格式化和清理而不是业务规则。在这里模仿域的类结构是很诱人的，但是如果你坚持使用适用于你的UI模型的平面DTO风格的类，那么整体上你会更容易。
DataAnnotations包含抽象或具体的“服务”类型，用于与UI 和域/持久层进行交互。因此，该项目依赖于Acme.Sales.UI.Services（域），Acme.Sales（抽象存储库）以及Acme.Sales.Entities，并处理这些不同层之间的所有映射活动。
Acme.Sales.UI其中Acme.Sales.UI.Impl类似Impl，Mvp，Mvc等。如果需要，可以从此命名空间中删除Mvvm，因为实现意味着它是什么。这通常依赖于UI项目，但会添加特定于特定UI模型的内容;控制器，演示者，视图模型等。这是您的实际“应用程序”。它也是您通常选择IoC容器（AutoFac，Ninject，Spring.NET，Castle，Unity）的地方，并将所有特定实现连接到抽象类型。
在您的应用程序项目中，您希望将逻辑概念分成不同的子命名空间/文件夹。例如，将您的演示者放在UI和Presenters中的视图 - 非常简单 - 如果您开始获得非常多的屏幕（例如Views和{{}，则在每个中创建子目录1}}）。在这里创建顶级Views.Billing目录/命名空间并在每个区域中放置单独的Views.Shipping，Area等也是可以的 - 这是ASP中目前采用的方法。 NET MVC。

您不需要将Presenters和Views分成不同的项目。请放心，您为MVP量身定制的视图对MVC或MVVM完全没用，反之亦然。模型驱动的应用程序中唯一真正有可能被重用的部分就是模型本身。

请注意，对于具有单个数据库和相对简单的域逻辑的应用，这只是一个非常基本的架构。它不包括任何更高级别的后端构造，如应用程序集成（例如Web服务），事件（pub / sub），批处理，CQS，ad-hoc报告等等。这些在大型商业应用程序中往往很常见，但如果您刚刚开始使用新的社交书签应用程序，则不需要任何复杂性。

另请注意：这是假设您计划至少一个中型项目 - 假设您和/或您的团队将在6个月或更长时间内工作。如果您计划在1个月或更短的时间内完成所有工作，那么请不要在解决方案架构上浪费您的时间。将它全部插入一个项目并为域，实体，和 UI重复使用相同的类 - ，只要项目足够小以便于理解，这是完全可以的。并保持。如果项目开始变成泥球，请仔细监控复杂性和维护开销，并考虑在较长时间内重构上述结构。

Answer 2

下面将是个不错的开始。如果项目变大，你可以分得更多：

Company.Project.Core -> Controller logic
Company.Project.Domain -> Domain models (view models and database models)
Company.Project.Interface -> Views, presenters

如何构建解决方案文件和文件夹以最适合MVP设计模式？

2 个答案: