小编Rob*_*ein的帖子

我(重新)设计大规模应用程序,我们使用基于DDD的多层架构.

我们有MVC与数据层(存储库的实现),域层(域模型的定义和接口 - 存储库,服务,工作单元),服务层(服务的实现).到目前为止,我们使用跨所有层的域模型(主要是实体),并且我们仅将DTO用作视图模型(在控制器中,服务返回域模型,并且控制器创建视图模型,其被传递到视图).

我读过很多关于使用,而不是使用,映射和传递DTO的文章.我知道没有任何确定的答案,但我不确定是否可以将域模型从服务返回到控制器.如果我返回域模型,它仍然永远不会传递给视图,因为控制器总是创建特定于视图的视图模型 - 在这种情况下,它似乎是合法的.另一方面,当域模型离开业务层(服务层)时感觉不对.有时服务需要返回域中未定义的数据对象,然后我们要么必须将新对象添加到未映射的域,要么创建POCO对象(这很丑陋,因为有些服务返回域模型,有些有效地返回DTO).

问题是 - 如果我们严格使用视图模型,是否可以将域模型一直返回到控制器,或者我们是否应该始终使用DTO与服务层进行通信？如果是这样,根据需要的服务调整域模型是否可以？(坦率地说,我不这么认为,因为服务应该消耗域名所具有的.)如果我们应该严格遵守DTO,它们应该在服务层中定义吗？(我想是的.)有时很明显我们应该使用DTO(例如,当服务执行大量业务逻辑并创建新对象时),有时很明显我们应该只使用域模型(例如,当成员服务返回贫血用户时( s) - 创建与域模型相同的DTO似乎没有多大意义) - 但我更喜欢一致性和良好实践.

Article Domain vs DTO vs ViewModel - 如何以及何时使用它们？(以及其他一些文章)与我的问题非常相似,但它没有回答这个问题.文章我应该用EF在存储库模式中实现DTO吗？也是类似的,但它不涉及DDD.

免责声明:我不打算只使用任何设计模式,因为它存在且很花哨,另一方面,我也想使用良好的设计模式和实践,因为它有助于设计整个应用程序,有助于分离至少在目前,即使是使用特定模式进行处理也不是"必要的".

一如既往,谢谢.

我想知道为什么这么少的现代网站仍然只使用PNG图标(但这个假设只是基于我的观察).到目前为止,我知道,使用PNG而不是SVG的主要原因是IE8和SVG使用更多的CPU功率(但我不认为这对于简单的1K图标来说是个问题).我可以看到(我们目前使用)使用SVG的许多优点,无论是作为精灵使用,还是作为图像使用,还是作为内联SVG使用.

(问题寻找研究:PNG Sprite vs SVG sprite vs Icon字体侧重于性能而没有相关答案,Icon Font与SVG缓存和网络关注的重点是网络流量,但它很容易通过模板解决.)

如果新网站仅支持现代浏览器,是否有任何理由不使用SVG(或者 - 是否有任何理由将PNG用于图标)？如果我们不关心IE8并且通过模板和/或缓存来支持SVG的使用,那么是否有任何依赖SVG的问题？

我无法找到Razor 3中的新功能.这似乎是一个愚蠢的问题,但我可以很容易地找到MVC 5中的新功能,在EF 6中等等 - 但我试着谷歌它,我试过asp.net,我试过斯科特的博客 - 什么都没有.所以我很好奇,有没有人真正知道Razor 3中的新功能？谢谢!

我有Repository模式的问题 - 如何在几个存储库之间执行JOIN操作.在这个项目中,我们使用MVC,EF,DDD.我知道这种问题已经出现过好几次了,我稍后会在这篇问题中提到这些问题.

在通用存储库模型(IRepository)和特定存储库模型之间,我选择了特定选项,因为我将ORM(在我们的例子中为EF)视为通用存储库模式本身,因此添加另一个通用存储库并没有意义而是根据域需求定制存储库.

问题是我有几个(~10个)表,每个表有很多行(数百万),我需要执行JOIN,所以使用IList或IEnumerable是不可行的选项.

我的理解(和我的观点)是IQueryable不应该离开存储库("DAL中会发生什么,应该留在DAL中.").暴露IQueryable并在LINQ服务中使用它会更简单,但它强烈违反了关注点的分离并破坏了存储库的作用 - 在这种情况下,服务将与存储库做同样的事情.为了选择一些,这些文章支持这种观点(或者更确切地说是信念):

要返回IQueryable <T>或不返回IQueryable <T>

我应该从DAL返回IEnumerable <T>还是IQueryable <T>？

http://www.shawnmclean.com/blog/2011/06/iqueryable-vs-ienumerable-in-the-repository-pattern/

http://blog.ploeh.dk/2012/03/26/IQueryableTisTightCoupling/

还有类似的问题和解决方案,例如如何使用存储库模式和实体框架加入多个表？建议.Include(),但这不是重载表和多个表连接的选项 - 对于每个JOIN,我们使用子选择来限制实际连接的内容.

这个问题(答案和评论) - 如何使用存储库模式查询交叉表？ - 基本上建议基于任务的区分:使用JOINS为查询创建一个存储库,并为每个实体创建"常规"存储库以进行操作.

我看到我们有这些选择:

1. 在服务中公开IQueryable并执行JOIN复杂查询; 我真诚地觉得这是反模式,我不喜欢这样.
2. 不要对这些~10个表使用Repository并在服务中执行查询; 一些文章建议使用EF就足够了(例如,是否可以绕过复杂查询的存储库模式？),我不同意这一点.
3. 使用基于任务的区分,不要限制存储库1:1 repo:entity(我赞成这个选项)
4. 完全不同的东西？

所以 - 你会建议什么？一次又一次,谢谢.