您能建议如何组织解决方案项目、文件、文件夹，使其与MVP设计模式相匹配，以表示模式思想吗?
我的意思是你会如何放置你的演示器，数据访问层，视图等。
谢谢
解决方案体系结构通常与您使用的UI体系结构相当独立，尽管如果您计划有多个UI应用程序(大多数项目都没有)，您可能会有一些额外的分离。
我倾向于用类似这样的模板开始:
-
Acme.Sales或Acme.Sales.Core-内部域/业务逻辑 -
Acme.Sales.Entities—用于持久层的数据实体。实体具有与核心(域)模型相似的类结构，但往往具有更薄的逻辑、附加属性(如Id)、双向关系(与域模型中的单向关系相反)以及ORM能够覆盖的virtual成员。该程序集通常还包括抽象存储库，用于对实体进行CRUD操作。 -
Acme.Sales.Entities.Impl，其中Impl类似于LinqToSql或NHibernate-此命名空间定义了实际持久化Entities的一种可能实现。抽象库的具体实现在这里。 -
Acme.Sales.UI包含与任何用户界面相关的常见类-可能是MVP GUI甚至CLI。与Entities一样，这些与Core类相似，但是倾向于具有特定于表示的逻辑和属性，例如验证和格式化(目前最常见的是通过DataAnnotations完成)。注意，核心库也应该验证，但是UI验证更倾向于格式化和清理输入，而不是业务规则。在这里模仿领域的类结构是很有吸引力的，但是如果您坚持为UI模型使用扁平的、dto样式的类，那么总体上您会更轻松。 -
Acme.Sales.UI.Services包含抽象或具体的"服务"类型，旨在与UI 和域/持久层进行交互。因此，该项目依赖于Acme.Sales(域)，Acme.Sales.Entities(抽象存储库)以及Acme.Sales.UI，并处理这些不同层之间的所有映射活动。 -
Acme.Sales.UI.Impl这里的Impl类似于Mvp、Mvc、Mvvm等等。如果需要，可以从这个名称空间中删除UI，因为实现暗示了它的含义。这通常需要依赖于UI项目，但将这些东西添加到特定的UI模型;控制器、呈现器、视图模型等。这是你实际的"应用"。这也是您通常选择IoC容器(AutoFac, Ninject, Spring)的地方。. NET, Castle, Unity)，并将所有特定的实现连接到抽象类型。 -
在您的应用程序项目中，您希望将逻辑概念分离到不同的子命名空间/文件夹中。例如，将演示器放在
Presenters中，将视图放在Views中——非常简单——如果你开始获得大量的屏幕(例如Views.Billing和Views.Shipping)，则在每个目录中创建子目录。也可以在这里创建顶级Area目录/命名空间，并在每个区域中单独放置Presenters,Views等-这是ASP目前采用的方法。净MVC。
您不需要将Presenters和Views分开到不同的项目中。请放心，您为MVP定制的视图对于MVC或MVVM将完全无用，反之亦然。模型驱动的应用程序中唯一有机会被重用的部分是模型本身。
请注意，这只是一个非常基本的架构，一个应用程序的单一数据库和相对简单的域逻辑。它不包括任何高级后端结构，如应用集成(例如web服务)、事件处理(发布/订阅)、批处理、CQS、特别报告等等。这些在大型商业应用中很常见，但如果你刚刚开始做一个新的社交书签应用，那么你不需要任何复杂的东西。
还要注意:这一切都是假设你正在计划一个至少中等规模的项目——假设你和/或你的团队将花费6个月或更长时间。如果您计划在1个月或更短的时间内完成所有内容，那么请不要在解决方案架构上浪费时间。把它们都塞进一个项目中，并为域、实体、和 UI - 重用相同的类是完全可以的，只要项目足够小，易于理解和维护。仔细监控复杂性和维护开销，如果项目开始变成一团泥，请考虑在较长一段时间内重构到上述结构。
下面是一个很好的开始。如果项目变得更大，你可以进一步分割:
Company.Project.Core -> Controller logic
Company.Project.Domain -> Domain models (view models and database models)
Company.Project.Interface -> Views, presenters