我应该为每个数据库使用一个类吗？

Question

首先，让我解释我在做什么。我需要下订单，将其分成不同的数据库，并打印出这个非常大的订单。我需要的是来自不同数据库的大约100列。我在做的方式是使用连接查询并将所有列值分配给一个大型Order类中的变量。这已经开始变得麻烦。我想知道的不是一个由100个左右的成员组成的类别。对于每个我使用的数据库，我应该只有一个类，然后使用它？

让我补充一点。基本上，将对象映射到原始数据库表或结果集更好。因为我有我的对象映射到结果集而不是单个表。

Answer 1

我在这里反对谷物，但我会说保持这个对象映射到结果集，并保持在数据库中的连接可能是一个更好的主意。

对于业务逻辑来说，一个“订单”通常是一个单一的内聚概念（至少，这是你如何开始框架）。它被映射到多个表（或数据库）的事实可能是数据如何被捕获的假象吗？在分解之前，我会问自己这些问题：

• 从其他对象组成顺序是否有明显的好处？
• 属性有不同的基数吗？即是一些每个订单和其他每行项目？
• 您可以重新使用组合对象的现有代码吗？
• 您是否启用了一些其他更容易处理多个对象的交互？

如果你不回答是肯定的任何的这些问题，我打赌你的代码会更简单，如果只用订单作为一个原子对象交易，并使数据库隐藏的复杂性更具可读性它来自哪里（你甚至可以使用一个视图）。

纯粹数量的属性通常不是分解接口的理由。但是，如果订单对象本身的复杂性（或大小）是什么让你失望，你可以尝试在内部简化它使用某种通用的访问方法，如：

private object GetOrderAttribute(string attributeName){ 
    // use a data structure (like a hash table) to store and access internally 
} 
... 
output("Quantity: " + GetOrderAttribute("quantity")); 
// etc. 

另外一个注意：当在逻辑系统设计中，性能应该很少成为开始的关注的问题，如果数据库执行连接，大多数涉及数据库表连接的情况会更好地执行，因为DBMS可以使用索引和其他机制高效地执行连接并避免从磁盘加载页面那是不需要的。也许你所有的查询都是这样做的，但通常情况下，这是数据库比业务逻辑代码更高效地执行一个数量级的事情。 （当然，如果连接跨越物理数据库边界，那么可能会失去该优点。）

Answer 2

这听起来像是你对我的偏好。你希望如何使用它？将它作为单独的C＃对象处理会更容易吗，还是将它作为多个SQL表处理更容易？

Answer 3

为什么不直接从个人数据库的数据加载数据？

例如，您的订单对象的构造是这样的：

Method New Order(orderId) { 
    Get Database 1 Details 
    Load Details into appropriate Variables 
    Get Database 2 Details 
    Load Details into appropriate Variables 
    Get Database **N** Details 
    Load Details into appropriate Variables 
} 

它可以更容易地保持其中涉及个人数据库的SQL并你不会有十几个不同的类别在那里为每个数据库。

另一种选择是有一个存储过程，它返回多个结果集，您可以通过代码中的DataSet访问这些结果集。

或者您可以通过将您的联接转换为您的数据库中的VIEW来更轻松地处理和维护联接。

你真的需要考虑的一件事是维护。在你没有阅读六个月之后，你维护代码的容易程度如何，或者对于其他开发人员在事先不了解代码的情况下维护代码有多容易。选择你认为最容易维护的范例，然后按照这种方式编码

Answer 4

我会推荐一个面向对象的解决方案。据推测，您的数据库设计有代表数据逻辑分组的表格。这些表中的每一个都可能映射到系统中的某个类，尽管在某些情况下，它可能不止是构成对象的一个​​表，也可能是表使用子类映射到的多个类。如果您需要显示来自多个表格的数据 - 例如说明与订单相关联的客户数据的订单列表 - 那么您可以使用视图，连接或存储过程来构建视图类的对象，该对象代表视图/连接/ sp中的选定数据。

本质上，我所描述的是一种N层数据架构，其中您有一个低级数据访问层，用于处理来自SQL方向的数据 - 表，视图，存储过程。在此之上可能是一个通用对象层，它处理通用数据对象并与数据访问层进行交互以存储/检索数据库中的对象。最后，在此之上，您有一个强类型的业务对象层，其中您的应用程序使用语义链接到您的应用程序的类 - 订单，客户，发票等。实现这种类型的通用体系结构有许多不同的模式，您应该调查几个，看看哪个适合你的应用需求最好。您可能希望直接使用像LINQ或nHibernate这样的对象关系映射，或者您可能希望将存储库分层存放在ORM之上。我个人认为，构建应用程序来处理域内上下文中的对象，而不仅仅是表格数据，将会改善您的代码。它应该提高可理解性和可维护性。您将能够在您的域类中封装行为，而不是在整个应用程序中传播。当然，这是假设你遵循良好的设计实践，但使用面向对象设计将会鼓励这一点。从显示逻辑中分离业务和数据逻辑也会使应用程序更具可测试性，同时将单一类分解为更小，更集中的相互关联的类。

Answer 5

我会考虑创建一个类来处理每个单独的数据存储中的数据。

然后，我会考虑使用一种模式，就像Facade一样将这些子系统组合在一起。在“设计模式”和“门面”上搜索网站以获取更多信息。然后，门面可以解释单独数据存储中数据之间的任何特定交互。

对我来说，维护逻辑上分组的代码要容易得多，而为单独的数据存储设置单独的类对我来说很有意义。

Answer 6

一个优雅和简单的方法来攻击这个问题是Active Record模式：

http://en.wikipedia.org/wiki/Active_record_pattern

当然，这可能不会在所有情况是可行的。它也可以与其他模式相结合，就像其他答案中所暗示的那样。无论您选择何种方式，我都相信您会面临权衡。祝一切顺利！