OO/DTO架构问题

我们有一个包含数据和方法的实体（类）（让我们称它为Person）。还有其他的类需要使用这个对象中的数据（让我们称其中一个Accountant），但是不需要使用它的方法中的功能。OO/DTO架构问题

将整个Person对象发送给Accountant还是创建一个新的PersonData对象来保存数据并将其发送给Accountant obj会更好吗？

我们确实有一个案例需要弄清楚，但我想知道最好的一般答案，以便我们可以在整个过程中使用它。所以在web服务或在智能客户端 - 例如

来源

2009-12-22 alchemical

通常，当您需要消耗一些序列化表单中的数据，你会伸手掀起了DTO。如果您只是在域中使用Person对象，并且已经正确封装，为什么还要创建DTO？

来源

2009-12-22 19:50:58 flesh

我会说OOP会让你使用person类中定义的'get'方法。我不会发送整个对象作为会计不需要整个对象，只是选择性数据。因为您正在创建不必要的大量冗余，所以我不会说后者。

但随后OOP这样是非常理想化的，因此它很可能是更好的做另一种方式......

来源

2009-12-22 19:52:57 silentcontributor

我一般准备金使用的DTO数据的跨层传输。如果情况并非如此，我不确定是否有创造一个令人信服的理由。

来源

2009-12-22 19:55:15 Tom

我认为这是一个信任界限的问题。在商业应用程序中，信任边界通常会决定您的图层体系结构。如果你的“会计师”在人的信任边界之外，那么应该有某种模型转换。架构和要求应该决定什么样的转换。

来源

2009-12-22 20:10:13

由别人说，有一个在使用，除非没有涉及转移的DTO没有真正的点... :)

的解决方案，我想建议，将抽象的传递给Accountant一个接口的对象IAccountee并有Person实现它......我不熟悉C＃（从您的个人资料，我infered这是你的选择:)语言），但这种可能应该指向你在正确的方向：

class Accountant { 
    //.... 
    public void performAction(IAccountee target) 
    { 

    } 
} 
interface IAccountee 
{ 
    string Name 
    { 
     get; 
    } 
    int Salary 
    { 
     get; 
     set; 
    } 
} 

class Person : IAccountee 
{ 
    //implementation here, as well as some stuff specific to Person 
}

基本上，这是在SOLID的D :) ......这是灵活和干净，也避免共享不必要的信息从Person与Accountant ...

据我所知，C＃接口不能要求变量（如在大多数语言中）/IDE功能生成默认的普通存取）如果你还没有这样做，但...这是一个有点耗费更多的时间比使用普通的变量，并且需要比一个普通字段访问更多的性能，但OTOH，这也是我所想考虑好的做法，至少在事情没有得到表现...我认为这绝对不是创建一个额外的DTO类和复制数据来回（或至少在一个方向上）更优雅......

希望帮助... ;）

来源

2009-12-22 20:33:23 back2dos

为什么你会使用IAccountee：是它只是为方便传递的变量或者是有什么我失踪？ – silentcontributor 2009-12-22 21:14:14

它会将个人会计从个人中分离出来，并将会计师本身不必要的所有内容都隐藏起来...... – back2dos 2009-12-22 21:44:55

啊，够公平的。谢谢。 – silentcontributor 2009-12-22 22:24:34

OO/DTO架构问题

回答

相关问题