使用 DTO 和 BO
我对 DTO/BO 的疑问之一是何时传递/返回 DTO 以及何时传递/返回 BO。
我的直觉告诉我始终将 NHibernate 映射到 DTO，而不是 BO，并且始终传递/返回 DTO。然后每当我需要执行业务逻辑时，我都会将 DTO 转换为 BO。
我这样做的方法是，我的 BO 将有一个构造函数，该构造函数接受一个参数，该参数是我的接口类型（定义所需的字段/属性），我的 DTO 和 BO 都将其作为唯一参数实现。
然后，我可以通过在构造函数中传递 DTO 来创建我的 BO（因为两者都实现相同的接口，它们都具有相同的属性），然后能够使用该 BO 执行我的业务逻辑。然后我还有一种方法将 BO 转换为 DTO。
然而，我也看到人们似乎只在后台使用 BO，并且只在后台使用 DTO，而对于用户来说，看起来好像没有 DTO。
与始终使用 BO 相比，此架构有哪些优点/缺点？
我是否应该始终传递/返回 DTO 或 BO 还是混合匹配（似乎混合和匹配可能会造成混乱）？
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)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这取决于您希望实现什么目标。我可以告诉你我自己做了什么 - 我在 NHibernate 中映射了 DTO 和 BO，但是 DTO 被映射为不可变的，因此我不会在不使用 BO 的情况下无意中更新数据库。
Web 服务中可访问的所有查询都会返回/接受 DTO。
每当从 DTO 更新时，我都会执行一个 UnitOfWork，在其中加载 BO，更新 DTO 的属性，如果它仍然有效，则再次保存它。
在客户端，每当客户端需要修改 BO 时，我都会从 DTO 创建 BO（AutoMapper 在这里绝对是一个有效的选择）。 BO 有一个构造函数，它接受所有参数来创建它，类似于 NHibernate 的做法。
好处是：
* 完全控制通过线路传输的数据量（DTO 通常是扁平化的，因此在第一次调用中仅发送关联类的 ID）。
* 我不必在两者中具有相同的属性
* 我可以根据需要混合搭配延迟加载
* 我可以在 DTO 中利用标量查询和其他计算属性，而无需在 BO 中创建它们。
* 对于不同的场景，每个 BO 可以有多个不同的 DTO。
所以，我想这将符合混合和匹配的条件，但有明确的指导方针，我会做什么:-)
希望这会有所帮助。
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.
也许你会发现这个：
http://automapper.codeplex.com/
也很有用。
Maybe you will find this:
http://automapper.codeplex.com/
useful too.
我知道这是一个相当老的问题，但让我对这个主题给出我的“十美分”。
在处理任何 MVC 项目（甚至使用 Entity Framework 或 NHibernate）时，我使用 POCO 进行持久性处理，使用 DTO/ViewModel 进行中间工作，因为行为扁平化、线上数据较少，最后（但并非最不重要），它们不要以任何方式暴露对象之间的关系。
我知道这听起来像是“灵丹妙药”，但至少它对我有用一段时间。
（请原谅一些英语错误=））
I know this is a quite old question, but let me give my "ten cents" about this subject.
When working with with any MVC project (even with Entity Framework or NHibernate), I use POCO for persistence and DTO/ViewModels for intermediate work, because of the flattened behaviour, less data on wire, and last (but not least valuable), they do not expose relations between objects in any way.
I know this may sound like a "silver bullet", but at least it's working for a while for me.
(forgive some english mistakes =) )