![]() |
1
0
我只是粗略地看了一下你的问题,如果我的回答是短视的,请原谅我,但这里是: 我不认为您可以从逻辑上摆脱从域对象到DTO的映射。 通过使用网线上的域对象,您将客户机和服务紧密耦合,所以首先要有一个服务的部分原因是为了促进松耦合。所以这是一个迫在眉睫的问题。 除此之外,你将最终得到一个脆弱的域逻辑接口,在那里你不能在不破坏你的客户端的情况下对服务进行更改。 我想最好的办法是实现一个松散耦合的服务,它实现一个REST/或其他一些松散耦合的接口。您可以使用automapper这样的产品来简化和简化转换,并在必要时展开数据结构。 在这一点上,我不知道有什么方法可以真正减少在做接口层时的繁琐工作,但我曾在一些大型项目上工作,但这些工作没有做出努力,我可以诚实地告诉你,节省下来的钱不值得。 |
![]() |
2
0
我认为你的问题围绕着这个问题: http://thatextramile.be/blog/2010/05/why-you-shouldnt-expose-your-entities-through-your-services/ 你是要还是不打算通过网络发送ORM实体? 因为你有一个面向服务的体系结构。。我(和作者一样)不推荐这种做法。 我用NHibernate。我称之为ORM实体。它们是POCO模型。但是它们有允许延迟加载的“虚拟”属性。
所以我做了很多“转换”。我水合ORM实体(用NHibernate)…然后我把它们转换成领域数据到对象。是的,一开始就很臭。 服务器将域数据发送到对象的。不存在延迟加载。我得用“Goldie Locks”“just right”模型填充它们。也就是说,如果我需要有一个级别的子级的父级,我必须预先知道这一点,并通过这种方式将域DTO发送给对象,并且只需适当的水合量。 当我把域数据发送回对象的(从客户机到服务器)时,我必须反转这个过程。我将域DTO对象转换为ORM实体。并允许NHibernate与ORM实体合作。 因为架构是“断开连接”的,所以我做了很多(NHiberntae)“.Merge()”调用。
合并是件好事。实体框架没有它。喝倒采。 这是一堆装置吗?对。 我觉得它完美吗?不。 然而。因为我向ORM发送的是非常基本的DTO(Poco's),这些DTO不是“有味道的”,所以我有能力切换ORM而不会破坏我与外界的合同。
很多人和我争论。他们说我做的太多了,ORM实体还不错。
英孚和NHibernate之间有足够的细微差别(或一些不那么细微的差别)来破坏游戏计划。 我的域DTO对象看起来95%像我的ORM实体吗?是的。但那5%会让你发疯。 从数据集迁移,尤其是如果它们是从TSQL中有大量biz逻辑的存储过程填充的,这并不是一件小事。但是现在我做了对象模型,而且我从来没有写过一个不是简单的CRUD函数的存储过程,我再也不会回去了。 我讨厌在存储过程中使用voodootsql的维护项目。现在不是1999年了。嗯,大多数地方。 祝你好运。
|
![]() |
user755806 · 从Rest服务返回JSON响应? 7 年前 |