.net - 我们应该在服务器和客户端上使用相同的业务类吗？

Question

假设您在服务器应用程序上有业务域模型，并且您将开发富客户端应用程序。

您可以使用 DTO 将数据传输到客户端并将更改传输到服务器或使用 WCF 服务并在客户端上生成新类。

另一种方法是传输与您在业务逻辑层中的服务器上使用的对象相同的对象。这些也可以是 ORM 使用的类。在这种情况下，类不应包含特定于服务器的逻辑，但它们可以包含一些通用逻辑。

我的问题是:

您使用哪种变体，您建议在新项目中使用哪种变体？

哪个更好？

在某些情况下，第二个更好吗？您如何描述这些情况？

有多少应用程序使用第一种/第二种方法？

在特定应用中如何选择？

Answer 1

我们只是很难在我们的项目中找到这个问题的答案。这是故事:

我们认为重用类很棒，并且会减少许多重复的东西。 NHibernate 允许从 session 中分离和重新附加类，所以这似乎是微不足道的。

我们遇到的第一个也是最大的问题是您无法发送整个数据库，因此我们必须将实体模型拆分为多个部分，并通过 guid 而不是普通引用将它们链接起来。这使得查询非常复杂。

我们必须实现一些技巧，因为序列化、持久性和数据绑定(bind)都有它们的问题。这个相当丑陋的黑客都进入了同一个类(class)。它们变得越来越大。

属性似乎是无害的，直到您看到每个类和每个属性的大量属性列表，因为每个层都添加了它的属性。

实体隐式开始支持两种“模式”:DTO 模式和持久性模式。当像 PrepareSerialization 这样的方法时，这一点变得很明显。或 AfterDatabaseRetrieval和其他类似的人出现了。某些属性只能在服务器中使用，其他属性只能在客户端中使用。

显然，维护变成了一场噩梦。没有人再冒更改实体的风险，因为您必须更改整个系统中的内容。

然后我们开始切换到 Dtos。

经过大量的工作，我们设法重写了系统的一些重要部分以使用 Dtos。而且——突然间，每个人都高兴了。

您可以维护序列化。您可以维护数据库模型并优化查询。您可以在不破坏任何东西的情况下对 cient 模型进行更改。

结论:与在所有层中使用相同类时失去可维护性相比，为每一层维护相似类的努力是荒谬的。

还有一些琐碎的实体和值类型的类同时用作实体和Dtos。

我可以想象一个只包含琐碎实体的小型应用程序可以在没有 Dtos 的情况下生存。