我们有一个基础产品，它为每个客户进行定制开发，扩展和覆盖基础功能。
我们还有一个自定义框架，基础产品位于其之上。
我们使用继承的表单来覆盖基本功能，并且迄今为止所有表单和类都已集中在同一项目中，即 UI、数据、业务...
我们现在需要清理代码库以允许多个客户端项目运行我立即开始研究基础产品，并在以下方面寻求建议：
- 组织解决方案以满足上述要求的方法，解决方案中的项目数量相当大，我们希望减少这个数量以提高开发人员的生产力，我们正在考虑制作框架 DLL 引用而不是项目引用
- 我们是否缺少任何构建和部署技巧，我们目前有半自动化的构建和发布过程
- 管理版本控制的最佳方法是什么
- 产品开发的任何最佳实践
We have a base product that has bespoke development for each client that extends and overwrites the functionality of the base.
We also have a custom framework that the base product and sits on top of.
We use inherited forms to override the base functionality and to date all the forms and classes have been lumped in the same projects i.e. UI, Data, Business...
We need to clean up the code base now to allow multiple client project to run off the base product at once and I was looking for advice around the following areas:
- Ways of organising the solution to fit with the above requirements, the number of projects in the solution is quite large and we want to reduce this to increase developer productivity, we are think of making the Framework DLL references instead of project references
- Are there any build and deployment tricks we are missing, we currently have a half automated build and release process
- What is the best way to manage versioning
- Any best practices for product development
发布评论
评论（2）
我个人坚信，高度模块化的架构非常适合这里：核心应用程序应该提供基本/通用服务，并且所有特定于客户的功能都应该作为插件实现（想想 MEF）。 因此，有几个想法：
I personally strongly believe that highly modular architecture will fit here nicely: core application should provide basic/common services, and all customer-specific functionality should be implemented as plug-ins (think MEF). Hence, several thoughts:
我可以就你的第一个问题以及第四个问题给你一个建议：如果我是你，我会选择一个框架 DLL 解决方案，该解决方案可以很容易地由团队管理和进一步开发，并为每个后续项目提供不同的解决方案。 然而，框架解决方案必须得到适当的开发，并特别注意一个设计原则：开放/封闭原则[1]，以便框架的未来开发不会破坏现有的实现。
[1] http://en.wikipedia.org/wiki/Open/close_principle
I can give you an advice on your first question and maybe a little of the forth : If i were you I would go with a framework DLL solution that could easily be managed and futher developed by a team and different solutions for each subsequest project. However, the framework solution would have to be propely developed, with extra care to one design principle: Open/closed principle [1] so future development of the framework does not break the existing implementations.
[1] http://en.wikipedia.org/wiki/Open/closed_principle