https://stackoverflow.com/questions/293915
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我有一个 VS 解决方案，包含以下项目。
-图形用户界面
-数据访问
-商业逻辑
-BusinessObjects
但是主模型类应该驻留在哪里呢？这通常是一组对象的缓存，这些对象是数据访问层和 GUI 使用虚拟网格查看模型内部数据的结果。使用 MVC 或 MVP 问题是一样的
想法？
解决方案
这是一个主观问题，但通常为了强制模型对象不直接依赖于基础设施，人们经常将它们放在单独的项目中。您还需要考虑哪些其他项目可能会使用这些模型对象。
将功能拆分为单独的可部署单元（程序集）的另一种选择是使团队可以更加独立地运作。根据部署频率和团队自主权来分隔项目。
最后，我看到了一些项目，其中模型对象被远程调用（例如使用 .NET 远程处理）并在与 Web 服务器分开的应用程序服务器上提供服务。我真的不推荐这种方法，但它是一种选择。
如果您不打算重复使用它们，并且您知道将它们放在同一个程序集中 允许 您可以与该项目中定义的任何其他内容创建交叉依赖关系，但您足够聪明，不会这样做，您可以将它们全部放在同一个项目中。
也就是说，99% 的时间我都有这些项目：
- 用户界面
- 核
- 坚持
- 测试
但您仍然必须考虑您的项目需求。
其他提示
我倾向于有
Justice.Project.Core— POCO 域模型 — 即业务对象）Justice.Project.Data— NHibernate 映射等，持久化方案所在的位置Justice.Project.Services— 存储库以及无法轻松融入业务对象的业务逻辑Justice.Project.(Web|UI)
该模型 是 - 或者 应该 – 业务对象。
我的解决方案有3个（非测试）项目
- 用户界面 - 显而易见
- 核心 - 所有域对象和业务逻辑
- 数据访问 - 用于填充/保存模型对象的存储库模式
我同意模型对象进入 POCO。所以我说我有一个订单 宾语。我的问题是我在哪里 存储集合的类 订单??
这取决于您的业务。很可能你会在几个不同的地方收集订单......
在您的客户对象上，每个客户都应该有一个订单集合，因此您可以在那里订购一个订单。
如果您有部门，每个部门都应该拥有他们创建的订单集合。
如果您有仓库，每个仓库可能都有一系列他们负责履行的订单。
有些对象没有父对象，这没关系。在我的系统中，我们有客户。客户的真实所有者是我们（业务），但没有<！>“我们<！>”;系统中的对象。如果您想获得一个客户列表（在我们的例子中），我们会在存储库中查询它。
IRespoistory<Client> repository = new Repository<Client>();
IList<Client> clients = repository.GetAllClients();
这同样适用于您的订单。
