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