首先，让我解释一下我在做什么。我需要一个订单，它被分成不同的数据库，并打印出这个非常大的订单。我从订单中需要的是来自不同数据库的大约 100 列左右。我所做的方式是使用连接查询并将所有列值分配给我的一个大型 Order 类中的一个变量。这已经开始变得麻烦了。我想知道不是有一个由 100 名左右的成员组成的班级来组成订单。我应该为我使用的每个数据库只设置一个类，然后使用它吗？
让我补充一下。基本上，将对象映射到原始数据库表还是结果集更好。因为我将对象映射到结果集而不是单个表。
【问题讨论】：
标签： c# database business-objects
我会推荐一个面向对象的解决方案。大概您的数据库设计有表示数据逻辑分组的表。这些表中的每一个都可能映射到系统中的一个类，尽管在某些情况下，它可能由多个表组成一个对象，或者一个表可能使用子类映射到多个类。如果您需要显示来自多个表的数据——比如一个订单列表以及与订单相关的客户的一些数据——那么你可以使用视图、连接或存储过程来构造一个视图类的对象，该对象表示view/join/sp 中选中的数据。
我所描述的本质上是一个 N 层数据架构，其中您有一个低级别的数据访问层，用于处理来自 SQL 方向的数据——表、视图、存储过程。在此之上可能是处理通用数据对象并与数据访问层接口以从数据库存储/检索对象的通用对象层。最后，在此之上，您有一个强类型的业务对象层，您的应用程序使用语义链接到您的应用程序的类——订单、客户、发票等。实现这种类型的通用架构有许多不同的模式，您应该调查几个，看看哪个最适合您的应用程序需要。您可能希望直接使用 LINQ 或 nHibernate 等对象关系映射，或者您可能希望在 ORM 之上分层存储库。
就个人而言，我认为构建应用程序以处理域上下文中的对象，而不是简单地作为表数据，将改进您的代码。它应该提高可理解性和可维护性。您将能够将行为封装在您的域类中，而不是将其传播到整个应用程序中。当然，这假设您遵循良好的设计实践，但使用 OO 设计会鼓励这一点。将业务和数据逻辑从显示逻辑中分离出来也将使您的应用程序更易于测试，将单体类分解为相互关联的更小、更集中的类。
【讨论】：
为什么不直接从单个数据库中加载数据？
例如，Order 对象的构造函数如下所示：
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
}
它可以更轻松地维护涉及各个 DB 的 sql，并且每个 DB 不会有十几个不同的类。
另一种选择是有一个存储过程，它返回多个结果集，您可以通过代码中的数据集访问这些结果集。
或者您可以通过将其转换为您的一个数据库中的视图来使您的联接更易于处理和维护。
您真正需要考虑的一件事是维护。六个月不读代码对你来说是多么容易维护，甚至对于其他一些开发人员来说，在没有先验知识的情况下维护代码是多么容易。选择您认为最容易维护的范例，然后以这种方式编写代码
【讨论】：
解决此问题的一种优雅而简单的方法是 Active Record 模式：
http://en.wikipedia.org/wiki/Active_record_pattern
当然，它可能并非在所有情况下都可行。正如其他答案所暗示的那样，它也可以与其他模式集成。我相信无论您选择哪种方法，您都将面临权衡取舍。万事如意！
【讨论】：
我在这里违背了规律，但我会说保持这个对象映射到结果集，并将连接保持在数据库中，可能是一个更好的主意。
对于业务逻辑，“订单”通常是一个单一的、有凝聚力的概念（至少，这就是您开始构建它的方式）。它被映射到多个表（或数据库）这一事实是否是数据捕获方式的产物？在分手之前我会问自己这些问题：
如果您对这些问题中的任何一个都没有回答是，我敢打赌，如果您的代码仅将订单作为原子对象处理，并且让数据库隐藏它所在位置的复杂性，那么它会更简单、更易读来自（您甚至可以为此使用视图）。
大量的属性通常不是分解接口的理由。但是，如果订单对象本身的复杂性（或大小）让您失望，您可以尝试在内部简化它以使用某种通用访问器方法，例如：
private object GetOrderAttribute(string attributeName){
// use a data structure (like a hash table) to store and access internally
}
...
output("Quantity: " + GetOrderAttribute("quantity"));
// etc.
另一个注意事项：虽然在逻辑系统设计中开始考虑性能很少，但如果数据库进行连接，大多数涉及数据库表连接的情况会执行得更好，因为 DBMS 可以使用索引和其他有效执行连接并避免从磁盘加载不需要的页面的机制。也许您所有的个人查询也这样做，但通常这是数据库可以比业务逻辑代码更有效地执行一个数量级的事情。 （当然，如果连接跨越物理数据库边界，则可能会失去这种优势。）
【讨论】：
这听起来就像你对我的偏好。您希望如何使用它？将其作为单独的 C# 对象使用会更容易，还是将其作为多个 SQL 表使用会更容易？
【讨论】：
我会考虑创建一个类来处理每个单独数据存储中的数据。
然后，我会考虑使用一种模式，比如 Facade 将这些子系统组合在一起。在网络上搜索“设计模式”和“外观”以获取更多信息。然后，外观可以解释单独数据存储中的数据之间的任何特定交互。
对我来说，维护逻辑分组的代码要容易得多，并且为单独的数据存储设置单独的类对我来说很有意义。
【讨论】：