作为对我上一个问题的扩展,关于为分离的层使用单独的项目- 解决方案的良好实践。
我现在想知道我是否将正确的功能放在正确的层中。
我正在从头构建一个WPF应用程序,它包含业务逻辑和业务对象。数据库本身位于web上的另一个具有访问权限的服务器上,仅限于使用OAuth身份验证的web调用。
我认为以下内容应该在这些层中。这个想法是,你从第一层到第四层,你只是取决于你下面的层。若要防止循环依赖,请执行以下操作。
WPF视图(用户将看到什么)
WPF ViewModel (程序如何响应用户交互)
没有WPF模型,因为它只是业务对象
存储库( ViewModel用于加载/保存业务对象的类)
通过选择正确的API调用来帮助保存对象的实用工具类。
业务对象/实体/DTO(以哪个名称为首选)
工厂(用于创建业务对象的存储库)
其他misc业务类(即当前登录用户的存储)
OAuth客户端(对存储库类使用的web服务器进行身份验证调用)
发布于 2011-11-09 09:34:34
您提到的四个层与我最近设计的两个公司解决方案时使用的分层名称相匹配。我也强烈同意@Konamiman的回复,数据访问和基础设施应该是两个独立的层。在我们的解决方案中,基础结构是一个横切层,可供任何层中的项目参考。在基础结构层中,我们保留日志功能、安全性和验证代码。
我还会考虑在数据访问层下添加一个名为实体的层。将所有业务对象放在那里,在数据访问层中添加实体的接口,并将数据访问层引用到实体项目中。
我习惯于使用非严格引用,如您所描述的,上层可以引用任何较低的层。在严格的引用中,上层应该只引用最近的下层。
发布于 2011-10-10 08:47:31
我有几个建议:
发布于 2011-12-10 19:28:47
存储库接口应该位于业务层(或)域层,这样您就可以针对您的域模型拥有不同的持久性实现。注意,接口属于客户端,而不是实现者。
数据访问逻辑( Data )可能在基础设施中,因为它涉及EF或NHibernate等技术。与该技术相关的所有内容,如UI框架、DB框架、日志框架实现,都可能位于基础结构层,您可以拥有Infrastructure.Crosscutting和Infrastructure.Data名称空间。
https://softwareengineering.stackexchange.com/questions/113393
复制相似问题