代码之家  ›  专栏  ›  技术社区  ›  ng5000

Sharing content between business objects and DTOs

  •  2
  • ng5000  · 技术社区  · 15 年前

    所有的,

    My typical approach for a medium sized WCF service would be something like:

    1. Define the interface using WCF data contracts and service operations. The data contracts would be POCO DTOs with no CRUD or domain logic.
    2. 使用完全特性的业务对象建模域。
    3. Provide some mechanism to go from DTO to BO and vice versa (see related question: Pattern/Strategy for creating BOs from DTOs )

    Now, a lot of the time (if not always) the data content of the business object and the DTO is near identical. How do people feel about creating a library of content objects which are shared by the BO and the DTO. E.g. if we had a WibbleDTO and a WibbleBO, we could create an IWibbleContent interface which both implement. We could even create an IWibbleContent interface and a WibbleContent class which both the DTO and BO hold a reference to.

    So, specific questions:

    1. Do you ever share content/data interfaces between your DTOs and BOs?
    2. 你是否曾经在DTOS和BOS之间共享数据内容类?

    如果不是这样的话,我想,根据我的相关问题,我们剩下的是冗长的代码复制,或者我们使用类似automapper的东西。

    Any comments appreciated.

    2 回复  |  直到 15 年前
        1
  •  2
  •   Stefan Steinegger    15 年前

    We are using quite similar approach as you describe with DTOs and BOs.

    我们很少有公共接口,要么是非常基本的接口(例如,获取businessid的接口),要么是特定于某个实现的接口,例如,可以在客户机或服务器上进行计算。

    We actually just copy properties. They are usually trivial enough that it is not worth to share code.

    At the end, more code is different then similar.

    • We have many attributes on these classes, which almost never are the same.
    • Most Properties are implemented as get; set; on the server, but with OnPropertyChangedEvent 在客户端上,它需要使用显式字段。
    • We don't share much code on client and server side. So there is no need for common interfaces.

    Even if many of the properties are the same on both classes, there is actually not much to share.

        2
  •  0
  •   Paul Speranza    15 年前

    我通常创建POCO,并通过我的所有层使用它们——数据访问Business to UI。在业务层中,我有一些经理,他们来回地重复POCO。我们将研究实体框架和/或NHibernate,因此我不确定这将导致我们。

    是的,我们写了一些额外的代码,但是我们保持每件事都很简单。我们正在使用MVC作为我们的用户界面,对我来说,这是一个天赐之物,与大部分的webforms相比,我再也不会回去了。现在我们的战斗应该是将JSON发送到Ajax回调或使用局部视图,后者是我们大多数时间所做的。

    Are we correct? Maybe not but it works for us. So many choices, so little time.