我正在编写一个标记方法的属性,以便它可以显示为单击时调用该方法的按钮。
应该为属性赋予我得到它的方法的 MethodInfo 似乎是合适的,并且它可以在屏幕上绘制自己并在单击时调用该方法。这样一来,课堂就很好而且自给自足。
但我从未见过包含其实际功能的属性类。它们始终只是其他类使用的数据容器。
是否存在与性能相关的实际原因,为什么应将功能排除在属性类之外?
我正在编写一个标记方法的属性,以便它可以显示为单击时调用该方法的按钮。
应该为属性赋予我得到它的方法的 MethodInfo 似乎是合适的,并且它可以在屏幕上绘制自己并在单击时调用该方法。这样一来,课堂就很好而且自给自足。
但我从未见过包含其实际功能的属性类。它们始终只是其他类使用的数据容器。
是否存在与性能相关的实际原因,为什么应将功能排除在属性类之外?
不,本身没有与性能相关的原因。更重要的是,属性是一种添加额外的声明性元数据以与反射一起使用的方式。
不将太多功能放入属性的一个原因通常是它们只接受构造函数中的编译时常量,因此您不会获得构造函数依赖注入。这通常通过使用依赖项的方法注入来解决。
ASP.NET MVC 对其AuthorizationFilterAttribute
及其派生属性执行此操作。您可以在此处查看ASP.NET 过滤器测试网站中带有“行为”的不同属性。
没有技术原因不能将代码放在属性类中。但是,有语义上的理由不这样做。
属性是元数据,即它们是声明性的。声明性信息说明了需要什么,而不是应该如何实现。
另一方面,代码是程序信息;它描述了某事是如何发生的。
同样,虽然没有技术原因不能混合声明性信息和程序性信息,但它可以被视为不好的做法。原因是两者混合会使代码更难阅读、更难测试和更难维护。这些并不能保证会发生,但与将两者分开时相比,往往需要付出更多的努力来避免这些问题。
事件(例如按钮单击)是声明性的,因此您使用属性进行事件处理的想法符合声明性模型。将事件处理、过程代码放在单独的类中可能更明智。