我有一个VS解决方案，包括以下项目。
-GUI
-DataAccess
-BusinessLogic
-BusinessObjects
但是主模型类应该驻留在哪里？这通常是一组对象的缓存，这些对象是来自数据访问层和GUI的结果，使用虚拟网格来查看模型内的数据。使用MVC或MVP
的问题是相同的想法？
答案 0 :(得分：2)
这是一个主观问题，但通常强制您的模型对象与基础架构没有直接依赖关系，人们经常将它们放在一个单独的项目中。您还需要考虑其他项目可能使用这些模型对象。
将功能拆分为单独的可部署单元（程序集）的另一个选择是团队可以更加独立地运行。根据部署频率和团队自主权分开项目。
最后，我看到了一些项目，其中模型对象被远程调用（如.NET远程处理），并在与Web服务器分开的应用程序服务器上提供。我真的不推荐这种方法，但它是一种选择。
如果您不打算重复使用它们，并且您认识到将它们放在同一个程序集中允许您创建与该项目中定义的任何其他内容的交叉依赖项，你足够聪明，不能这样做，你可以将它们全部放在同一个项目中。
那就是说，99％的时间我都有这些项目：
但是你仍然需要考虑你的项目需求。
答案 1 :(得分：1)
我倾向于
Justice.Project.Core - POCO域模型 - 即业务对象）Justice.Project.Data - 持久性方案所在的NHibernate映射等Justice.Project.Services - 存储库以及无法轻松融入业务对象的业务逻辑Justice.Project.(Web|UI) 模型 - 或应该是 - 业务对象。
答案 2 :(得分：0)
我的解决方案有3个（非测试）项目
答案 3 :(得分：0)
我同意模型对象进入 POCO。所以我说我有一个订单 宾语。我的问题是我在哪里 存储集合的类 订单??
这取决于您的业务。很可能你会在几个不同的地方收集订单......
在您的客户对象上，每个客户都应该有一个订单集合，因此您可以在那里订购一个订单。
如果您有部门，每个部门都应该拥有他们创建的订单集合。
如果您有仓库，每个仓库可能都有一系列他们负责履行的订单。
有些对象没有父对象，这没关系。在我的系统中，我们有客户。客户的真实所有者是我们（业务），但系统中没有“我们”对象。如果您想获得一个客户列表（在我们的例子中），我们会在存储库中查询它。
IRespoistory<Client> repository = new Repository<Client>();
IList<Client> clients = repository.GetAllClients();
这同样适用于您的订单。