我需要开发一个包含两个主要部分的应用程序:
- 具有特定业务类(例如书籍、图书馆、作者...)的业务逻辑部分
- 一个通用部分，可以在数据网格中显示书籍、图书馆......，将它们映射到数据库......)。
通用部分使用反射从业务类中获取数据，而无需在业务类中编写特定的数据网格或数据库逻辑。这工作正常，允许我们添加新的业务类(例如 LibraryMember)，而无需调整数据网格和数据库逻辑。
然而，多年来，代码被添加到业务类中，这些代码也利用反射来完成业务类中的事情。例如。如果一本书的作者改变了，观察者被调用来告诉作者本身应该将这本书添加到他所写的书籍集合中(Author.Books)。在这些观察者中，不仅传递了实例，还传递了直接从反射中获得的信息(将 FieldInfo 添加到观察者调用中，以便调用者知道该书的字段“Author”已更改)。
我可以清楚地看到在这些通用模块(如数据网格或数据库接口(interface))中使用反射的优势，但在我看来，在业务类中使用反射并不是一个好主意。毕竟，应用程序不应该尽可能不依赖反射来工作吗？还是使用反射是 21 世纪的“正常工作方式”？
在您的业务逻辑中使用反射是好的做法吗？
编辑:对柯克言论的一些澄清:
- 假设 Author 在 Book 上实现了一个观察者。
- 只要 Book 的某些字段发生变化(例如 Title、Year、#Pages、Author 等)，Book 就会调用它的所有观察者。已更改字段的“FieldInfo”在观察者中传递。
- 作者-观察者然后使用此 FieldInfo 来决定它是否对此更改感兴趣。在这种情况下，如果 FieldInfo 用于字段 Author of Book，Author-Observer 将更新其自己的 Books 向量。
最佳答案
反射的主要危险是灵 active 会升级为杂乱无章、无法维护的代码，特别是如果使用更多初级开发人员进行更改时，他们可能不完全理解反射代码或者非常迷恋反射代码以至于他们使用它来解决所有问题，即使更简单的工具就足够了。
我的观察是过度概括会导致过度复杂化。当通用设计无法适应实际边界情况时，情况会变得更糟，需要 hack 才能按计划适应新功能，将灵 active 转化为复杂性。
关于c# - 在您的业务逻辑中使用反射是好的做法吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3924509/