1

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

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

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

这个想法是有一个基础项目(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程序集,该程序集可能包含方法的覆盖或对象的扩展、额外字段等等

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

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

最好的问候
罗伯特

4

1 回答 1

1

我的两个建议,从你说的:

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

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

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

于 2009-06-08T16:29:14.223 回答