标签:c net entity-framework dto domain-driven-design
我正在编写一个控制台应用程序,它可以从存储过程记录集中进行大量数据检索.对于我正在使用的每个记录集类型,我有一个使用EF和自定义复杂类型的Repository来检索数据:
public interface IBalanceSheetRepository
{
IEnumerable<BalanceSheetRecordDTO> GetBalanceSheetRecords();
}
public class BalanceSheetRepository : IBalanceSheetRepository
{
DBContext _context;
...
public IEnumerable<BalanceSheetRecordDTO> GetBalanceSheetRecords()
{
ObjectResult<BalanceSheetRecord> results = _context.GetBalanceSheet();
return results.Select(CreateBalanceSheetDTOFromDAO);
}
private static BalanceSheetRecordDTO CreateBalanceSheetDTOFromDAO(BalanceSheetRecord dao)
{
return new BalanceSheetRecordDTO { ... };
}
}
这里,BalanceSheetRecord是我在设计器中创建的复杂数据类型.我创建了一个DTO以避免耦合,因为BLL不应该知道BalanceSheetRecord类型.
这是我的问题:由于DTO类型用于存储库接口的方法签名,并且因为我的BLL最终将使用存储库&返回DTO的集合,这似乎是一个贯穿各领域的关注点.因此,我让DTO与repo接口一起生活在一个单独的“Infrastructure”组件中.这是我努力实现的良好做法,还是我在某个地方转错了?
另外:在我的存储库中新建数据上下文是不好的做法?当两个组件都属于DAL时,是否有一定量的耦合?我想使用DI,但是对于替换TestBalanceSheetRepository的repo的DBContext实现似乎更有用.
解决方法:
我更喜欢从我的存储库返回实际实体.这样,当您需要协调服务层中不同实体之间的复杂交互时,就不会来回转换到DTO.然后,当将数据返回到应用程序层时,服务层将实体投影到DTO中.
我知道有些纯粹主义者说层之间的所有互动都应该用DTO来完成,但我发现这是不切实际的.无论如何,服务层将最终耦合到实体,因此它不像你正在添加耦合.
它还限制了DTO到实体到服务层的投影/展平.对我来说这是一个加分,因为这些活动增加了复杂性并降低了性能.
您的数据上下文是您的工作单元. “每个存储库的一个工作单元”的想法是一种反模式.工作单元应由服务层确定范围,这可能涉及来自1-many存储库的1-many实体.如果每个存储库具有不同的工作单元,则您无法轻松地使服务层调用保持一致的事务.
标签:c,net,entity-framework,dto,domain-driven-design 来源: https://codeday.me/bug/20190518/1127932.html
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。