问题描述
关于DTOs / BO的一个问题是关于何时通过/返回DTO以及何时通过/返回BO。我的直觉反应告诉我总是将NHibernate映射到DTO，而不是BO，并且始终通过/返回DTO。那么当我需要执行业务逻辑时，我会将我的DTO转换成BO。
我将这样做的方式是，我的BO将有一个构造函数，它接受一个参数，该参数是我的接口类型（定义必需的字段/属性）我的DTO和BO都是唯一的参数。
然后，我可以通过在构造函数中传递DTO来创建我的BO（因为实现相同的接口，它们都具有相同的属性）和那么可以用那个BO来执行我的业务逻辑。那么我也会有一种将BO转换为DTO的方法。
然而，我也看到人们似乎只与BO一起工作，只能在用户的背景下使用DTO，看起来没有DTO。
这个架构有什么好处/垮台，而不是总是使用BO？
我应该经常传递/返回DTO或BO或混合（似乎混合和匹配可能会混乱）？
这取决于你希望实现。我可以告诉你我自己做了什么 - 我已经在NHibernate中映射了DTO和BO，但DTO被映射为不可变的，所以我不会在不使用BO的情况下不经意地更新数据库。
WebServices中可访问的所有查询返回/接受DTO。
无论何时从DTO更新，我都做一个UnitOfWork，在那里我加载BO ，从DTO更新属性，如果仍然有效，请再次保存。
在客户端上，我从DTO创建BO（AutoMapper是一个有效的选择这里）每当客户端需要修改它。 BO有一个ctor，它采用所有参数来创建它，类似于NHibernate会做的。
其优点是：
*对数据量的总体控制通过线路（DTO通常被平坦化，因此只有相关类的Id在第一次呼叫中发送）。
*我不必在
*中拥有相同的属性我可以混合和匹配延迟加载，因为我希望
*我可以使用DTO中的标量查询和其他计算属性没有在BO中创建它们。
*对于不同的场景，我可以为每个BO提供几个不同的DTO。
所以，我想这将符合混合和匹配的条件，做： - ）
希望这有帮助。
One area of question for me about DTOs/BOs is about when to pass/return the DTOs and when to pass/return the BOs.
My gut reaction tells me to always map NHibernate to the DTOs, not BOs, and always pass/return the DTOs. Then whenever I needed to perform business logic, I would convert my DTO into a BO.
The way I would do this is that my BO would have a have a constructor that takes a parameter that is the type of my interface (that defines the required fields/properties) that both my DTO and BO implement as the only argument.
Then I would be able to create my BO by passing it the DTO in the constructor (since both with implement the same interface, they both with have the same properties) and then be able to perform my business logic with that BO. I would then also have a way to convert a BO to a DTO.
However, I have also seen where people seem to only work with BOs and only work with DTOs in the background where to the user, it looks like there are no DTOs.
What benefits/downfalls are there with this architecture vs always using BO's?
Should I always being passing/returning either DTOs or BOs or mix and match (seems like mixing and matching could get confusing)?
It depends on what you wish to achieve. I can tell you what I do myself - I have both the DTO and the BO mapped in NHibernate, but the DTOs are mapped as immutable, so I don't inadvertedly update the database without using a BO.
All queries accessible in the WebServices return/accept DTOs.
Whenever updating from a DTO, I do a UnitOfWork, where I load the BO, update the properties from the DTO and save it again if it is still valid.
On the client, I create the BO from the DTO (AutoMapper is definetly a valid choice here) whenever the client needs to modify it. The BO has a ctor that takes all arguments to create it similar to what NHibernate would do.
The benefits are:* Total control over the amount of data that goes over the wire (The DTO's are typically flattened, so only the Id of associated classes are sent in the first call).* I don't have to have the same properties in both* I can mix and match lazy-loading as I wish* I can utilize scalar queries and other calculated properties in the DTOs without creating them in the BO.* I can have several different DTOs per BO for different scenarios.
So, I guess that would qualify as mixing and matching, but with clear guidelines where I do which :-)
Hope this helps.
这篇关于使用DTO和BO的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！