使用编译时编织进行依赖注入？

作者: 只怕再见是故人
发布时间: 2024-09-17 10:19:21 (2天前)

2 条回复

1#
回复此人
春风助手 | 2020-08-11 10-24

我认为您在这里不会丢失任何内容，而限制的确是使用编译时编织的结果。尽管我认为编译时编织工具在软件开发中占有一席之地，但我认为它们经常被过度使用。我经常看到它们被用来修补应用程序设计中的缺陷。在我构建的应用程序中，我将通用接口应用于某些体系结构概念。例如，我定义： ICommandHandler<TCommand>实现特定用例的服务的接口； IQueryHandler<TQuery, TResult>用于执行查询的服务的接口； IRepository<TEntity>作为存储库抽象的接口； IValidator<TCommand>用于执行消息验证的组件的接口；等等等等。这使我可以为此类工件创建单个通用装饰器（例如TransactionCommandHandlerDecorator<TCommand>，允许在其自己的事务中运行每个用例的）。装饰器的使用具有许多优点，例如：这些通用装饰器完全与工具无关，因为没有引用代码编织工具或拦截库。PostSharp方面完全依赖于PostSharp，并且拦截器始终依赖于拦截框架，例如Castle.DynamicProxy。因为装饰器只是一个普通的组件，所以可以将依赖项注入到构造函数中，并且当您使用“依赖项注入”来构成对象图时，它们可以发挥正常的作用。装饰器代码很干净，因为缺少与任何第三方工具的依赖关系。因为它们与工具无关，并且允许依赖项注入，所以可以轻松对装饰器进行单元测试，而无需使用特殊技巧。由于无需在编译时编入装饰器，因此也可以轻松地单独测试需要应用跨领域关注点的应用程序代码。当装饰器在编译时被编织时，您总是被迫对应用程序代码进行集成式测试，或者需要还原为特殊的构建技巧以防止将其应用于单元测试项目中。装饰器可以在运行时动态且有条件地应用，因为无需进行编译时代码编制。与代码编织相比，性能是相同的（甚至更快），因为在对象构造过程中不会发生反射。无需使用属性标记组件即可注意到必须应用某些方面。这使您的应用程序代码无需任何有关此类交叉问题的知识，并使替换它变得更加容易。

编辑

登录后才能参与评论