创建 n 层解决方案时，我不想公开我的业务对象，而是使用 DTO 来代替它。另一方面，我不想重复定义对象并一直编写复制代码。
现在我的想法是编写包含所有必需字段和属性但不包含逻辑（仅状态）的 DTO。
然后，我将从这些 DTO 中派生出我的业务对象，用我的业务逻辑扩展它们，处理 DTO 基类属性。这些对象也将是持久保存在所使用的 ORM (NHibernate) 中的对象。
通过这种方法，在服务器端，我可以处理业务对象并将它们直接传递给客户端（它们是派生的，因此可向下转换）。我不会被迫以这种方式公开我的业务逻辑并节省大量代码。
您认为这种做法明智吗？
问候，
塞巴斯蒂安
When creating an n-tier solution, I don't want to expose my business objects, but use DTO's instead of this. On the other side, I don't want to doubly define objects and write copy-code all the time.
Now my idea would be to write DTOs that contain all necessary fields and properties, but no logic (only state).
Then I would derive my business objects from those DTOs, extending them with my business logic, working on the DTO base classes properties. These objects also would be the objects persisted in the ORM used (NHibernate).
With that approach, on the server side I could work on the business objects and pass them directly to the client (they are derived, so down-castable). I would not be forced to expose my business logic that way and save a lot of code.
Do you think that approach is sensible?
Regards,
Sebastian
发布评论
评论（3）
您可能需要考虑以下事项：
模式与实践：数据传输对象
另外，我自己没有使用过它，但你可能想看看 AutoMapper 也是如此。
You may want to consider the following:
from Pattern and Practice: Data Transfer Object
Also, I have not used it by myself, but you may want to check out AutoMapper as well.
对我来说听起来很合理。在 Linq to SQL 中，业务对象是通过使用部分类从 DTO 派生的。
Sounds reasonable to me. In Linq to SQL, business objects are derived from the DTO's by the use of partial classes.
“然后我将从这些 DTO 中派生出我的业务对象”请记住，DTO 可能看起来与 BO 不同，它们可能包含来自 2 或 3 个 BO 的属性
"Then I would derive my business objects from those DTOs" Have in mind that DTOs might look different from BO they might contain properties from 2 or 3 BO