使用抽象基类时在何处进行独特调整

时间:2009-06-08 15:58:15

标签: .net architecture assemblies abstract-class external

我在决定走哪条路时遇到了一些麻烦...... 我有这个应用程序,它包含一个基础项目和一个应用程序项目,应用程序项目包含针对特定系统的代码,系统应用程序。

基础项目是一个抽象类,包含每个系统特定应用程序项目实现的抽象方法。
问题是系统应用程序项目可能/将有客户特定的调整,我不想将此代码放在系统应用程序程序集中。

我不确定从哪里开始或如何以未来安全的方式完成此任务,易于维护,并且我可以添加更多客户特定代码而无需重写系统应用程序程序集。

我们的想法是为每个系统(dll)创建一个基础项目(dll),一个系统应用程序项目,然后将客户特定的调整放在一个客户唯一项目(dll)中。
Rob.Core.dll
Rob.Application.BigSystem.dll
Rob.Application.BigSystem.Customer.BigCompany的.dll

Rob.Core.dll 是基础抽象项目。
Rob.Application.BigSystem.dll 是一个特定于系统的项目( BigSystem ),派生自 Rob.Core.dll
Rob.Application.BigSystem.dll 应检查当前客户 BigCompany 是否有任何独特的调整,如果是,请加载 Rob.Application。 BigSystem.Customer.BigCompany.dll 程序集,可能包含方法或对象扩展的替代,额外字段等。

好的,总结一下...... 我不知道在这里走哪条路,我可以创建一个基础项目(抽象),并从每个系统特定的项目派生出来,似乎这是开始的方式。
然后为每个客户创建一个具有一组唯一调整的新项目,并覆盖系统特定项目中的所有方法。
问题是,哪个项目是在运行时执行的项目?系统特定项目或客户独特项目?
如果系统特定项目执行如何加载所有客户调整(如果有的话,不是每个客户都有独特的调整)?

这是一个非常大的问题,但我希望有一些技巧可以帮助我编写架构。

最好的问候 罗伯特

1 个答案:

答案 0 :(得分:1)

我的两条建议,来自你所说的:

我会专注于类型,而不是项目。 “Projects”只是一种创建一个充满可用类型的程序集的方法 - 它们本身不会继承任何东西,它们也不允许子类化等。我会问的问题是:需要哪些类型为客户定制?这种定制将如何发生?

一旦你了解了这些 - 我建议研究依赖注入或可扩展性框架。一个好的DI框架可以Ninject。一个良好的可扩展性框架是MEF

如果总是需要以客户特定的方式提供类型,那么您可能希望专注于DI。如果类型是默认行为的可选扩展,那么只需执行某种形式的插件系统/可扩展性系统(如MEF)就可以更简单。