C# 有时候，将业务逻辑和数据结构结合起来是个好主意吗？

最近有人告诉我，如果编写一个数据结构，目前只需要一种类型的业务逻辑，那么我应该将所有逻辑直接构建到类中，并且只担心在结构需要不同逻辑时将其移动到单独的类中

我的问题是：这是一个好的实践，还是如果业务逻辑有可能发生变化，那么最好从一开始就将逻辑和结构分开

---

我的直觉是保持逻辑分离，因为这似乎遵循开放/封闭原则，而结构和逻辑的结合似乎违反了SRP。

这是一个相当主观的问题，本质上触及了面向对象编程的核心，在面向对象编程中，数据和逻辑的结合是规范。如果数据结构用于与另一个系统通信（基本上遵循接口定义语言方法），或者如果存在逻辑特定于非常特定的上下文的情况，我通常倾向于将数据结构与相关逻辑分开

在面向对象语言中的列表、队列和字典等情况下，数据和逻辑组合形成一个内聚对象，并且相互依赖。在这种情况下，在像C#这样的面向对象语言中，分离逻辑和数据是没有意义的

然而，在其他特定情况下，将数据和逻辑分开是有意义的。例如，如果您正在创建一个Invoice对象，并且它需要由任意数量的下游系统进行处理，那么您不希望将这些下游系统的逻辑放入发票中。相反，这种逻辑应该分开

所以，我想简单的答案是：这真的取决于你在做什么

希望这有帮助，

---

Nate

另一方面，您是否可能构建不包含自身逻辑的数据结构？另请参见@Damien_The_unsiver数据结构需要（也应该）包含的唯一逻辑是如何存储和查询通用数据。@delnan-好的，这是对整个面向对象方法的拒绝。我并不是说这是错的，只是它还不一定是主流。@Damien_不信者不，这是关注点的分离。你是说“整个面向对象的方法”由混合的关注点组成，比如组织对象和这些对象的行为？那将是新闻。这一原则是非常主流的，基本上每种语言的标准库容器都遵循这一原则。看看Java的集合、C++的标准容器、C#的

系统、集合

，等等@Damien_The_unsiver，很多很多数据结构都不包含自己的逻辑。例如，看匿名类型的每一个用法。同意列表等等。我想我想问的是。。。若我需要从类型Foo转换为类型List，我不会将List扩展为使用Foo作为newlist（Foo）或List.Add（Foo）。我会创建一个方法或接口来处理翻译并返回列表。类似地，对于数据库，我可能有一个允许添加、删除、创建等的类，但是使用数据库的Add（）方法，获取原始数据并将其放入数据库的逻辑是分开的。是这样吗？“有时将两者结合起来是正确的吗？”乔希，这也要视情况而定。在数据库的情况下，我大体上同意您的观点，并且不将数据结构与数据库代码结合起来，因为它确实代表了一种非常强的关注点分离。但是，有一种非常流行的模式称为ActiveRecord（有关详细信息，请参阅和），它将类似于database.Add（）方法的内容与数据结构相结合。