在业务逻辑中使用反射是否是一种好的做法？

我需要在一个由两个主要部分组成的应用程序工作：在业务逻辑中使用反射是否是一种好的做法？

业务逻辑部分的具体业务类（如图书，图书馆，作者，...）
通用部分，可在数据网格中显示Books，Libraries，...，将它们映射到数据库...）。

泛型部分使用反射来从业务类中获取数据，而无需在业务类中编写特定的数据网格或数据库逻辑。这工作得很好，并允许我们无需调整数据网格和数据库逻辑增加新的业务类（例如LibraryMember）。

但是，多年来，代码被添加到业务类中，这些业务类还利用反射来完成业务类中的事情。例如。如果一本书的作者被改变，观察家们打电话告诉作者本身，它应该本书添加到其收藏的由他（Author.Books）写的书。在这些观察员，不仅实例都过去了，而且还直接从反思中得到的信息（这样，来电者知道，这本书领域的“作者”是改变字段信息添加到观察者调用）。

我可以清楚地看到在这些通用模块（如数据网格或数据库接口）中使用反射的优点，但在我看来，在业务类中使用反射是一个坏主意。毕竟，应用程序不应该尽量不依赖反思工作？还是在21世纪反思“正常工作方式”？

是因为你的业务逻辑使用反射好的做法呢？

编辑：一些澄清柯克的一句话：

试想一下，作者实现对图书的观察员。
书呼吁所有的观察者只要书的某些领域改变（如名称，年份#Pages，作者，...）。更改字段的'FieldInfo'在观察者中传递。
的作者，然后观察者使用该字段信息，以决定是否有兴趣在这个变化。在这种情况下，如果FieldInfo用于Book的字段Author，则Author-Observer将更新其自己的Books矢量。

来源

2010-10-13 Patrick

你说'FieldInfo'通过，但我没有看到你解释如何使用它。具体而言，（除了传递信息类，这是相对无害的）如何使用反射？ – 2010-10-13 14:15:48

你使用它像INotifyPropertyChanged接口（通常在WPF应用程序中使用数据绑定）？在属性设置时引发事件，使用属性名称？ – 2010-10-13 14:42:56

@Amittai：不，这是一个相当自定义，使用反射的非常具体的实现。 – Patrick 2010-10-13 14:56:05

我避免使用反射。是的，它使您的程序更加灵活。但是这种灵活性的代价很高：没有编译时检查字段名称或类型，或者通过反射收集的任何信息。

像很多事情一样，这取决于你在做什么。如果你的逻辑性质是你永远不会比较发现的字段名称（或其他）到一个常量值，那么使用反射可能是一件好事。但是，如果您使用反射来查找字段名称，然后循环搜索名为“作者”和“标题”的字段，则可以使用两个命名字段创建一个更复杂的对象模拟。如果您在字段实际称为“AuthorName”时搜索“作者”，或者您打算搜索“作者”并意外键入“Auhtor”？现在，您的错误将在运行时才显示出来，而不是在编译时标记出来。

使用硬编码的字段名称，您的IDE可以告诉您每个地方使用某个字段。有反思......不太容易说出来。也许你可以对名称进行文本搜索，但是如果字段名称作为变量传递，它可能会变得非常困难。

我正在研究一个原始作者喜欢反射和类似技术的系统。有各种各样的地方他们需要创建一个类的实例，而不是仅仅说“新”和类，他们创建一个令牌，他们在表中查找以获取类名称。这会得到什么？是的，我们可以更改表格以将该标记映射到不同的名称。这使我们获益...什么？你最后一次说什么时候，“哦，我的程序创建客户实例的每个地方，我想要更改为创建NewKindOfCustomer的实例。”如果你对班级有所改变，你可以改变班级，不要创建一个新班级，而是留着旧班级留恋。

采取类似的问题，我随时进行构建数据输入屏幕的常规做法通过询问数据库字段名称，类型和大小的列表，然后从那里铺设出来。这给了我使用同样的程序对所有简单的数据输入屏幕的优势 - 只是通过在表名作为参数 - 如果一个字段添加或删除，则需要零代码的变化。但是，只要我不在乎这些领域是什么，这只会起作用。一旦我开始有验证或副作用具体到这个画面，该系统是更多的麻烦比它的价值，和我最好回落到更明确的编码。

来源

2010-10-13 14:49:54 Jay