-
08-07-2019 - |
题
我有一个 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();
这同样适用于您的订单。