【发布时间】:2014-04-25 16:13:20
【问题描述】:
我有一系列类,它们有许多类似的Shared 方法,我想确保在每个类中以一致的方式实现这些方法。这些Shared 方法在代码的各个区域通过反射调用,到目前为止,我一直在手动使它们保持同步。随着类数量的增长,确保同步变得有点乏味——当我向范例中添加一个新的Shared 方法时,确保它确实在所有类中实现以防止运行时的过程也是如此当反射来寻找错误时。
我最初认为这将是接口的理想用途,但对于不同的线程(例如Why we can not have Shared(static) function/methods in an interface/abstract class?),您不能将Shared 方法定义为接口的一部分。然后我尝试定义一个公共基类并标记这些方法MustOverride,但你也不能这样做。我已经研究过委托(我以前没有使用过),但它似乎允许与我试图做的相反(即,委托似乎允许从多个类而不是多个类的共同需求的独特实现)。
因此,VB.Net 中是否有一种方法可以确保在编译时我的每个类都以一致的方式实现一组常见的共享方法和函数?
附带说明一下,这些类目前都是 Entity Framework 类的扩展,并且正在被混合到 EF 类中。
编辑:作为语言功能(可能不存在)的替代方案,我也愿意接受有关提供此类功能的任何重构类型工具的建议。
【问题讨论】:
-
模板设计模式能帮到你吗? “在操作中定义算法的骨架,将一些步骤推迟到子类。” [链接]dofactory.com/Patterns/PatternTemplate.aspx[link].我用它来创建类似步骤(例如验证和更新)的“大纲”,其中要完成的确切验证和更新因类而异。
-
@phaedra 呵呵……这正是我正在做的。我使用反射来调用(并尝试模板化)的部分确实是处理非常特定功能的小步骤。大多数都不到 10 行。
-
这是一个 XY 问题。当然,您问这个问题的唯一原因是因为您担心反射代码在运行时失败,但没有任何好方法让编译器帮助您避免它。您可以通过不使用反射来做到这一点。这完全是使用 ORM 框架的重点。像实体框架。正确使用工具。
-
@Hans 在几个(但不是全部)情况下,模板化代码不会触及 EF,因此我是否“正确使用 EF”并不总是一个密切相关的问题。我顺便提到它只是为了建议它是否会影响可能的解决方案(例如,在定义一个公共基类时,我需要在 System.Data.Objects.DataClasses.EntityObject 和我自己的继承层次结构中的类之间获取) .
-
@Hans 与软件工程中最感兴趣的任何事情一样,我正在平衡两个相反的约束:使用集中反射实例的运行时错误风险,与维护这个特定的固有风险应用程序类似的 UI 和业务逻辑集。恭敬地,更有用的是解决方案/答案(包括“在 VB.Net 中真的没有办法做你想做的事”,如果是这样的话),而不是简单地说“正确使用 EF”,而这并不是问题的真正症结所在。
标签: asp.net vb.net entity-framework abstract-class shared