什么是一个很好的解决方案结构，以便在每个客户端的基础产品的轻松定制？ [英] What is a good solution structure to allow easy customisation of a product on a per client basis?
问题描述
我要寻找关于如何允许在每个客户端的基础上很容易定制和核心产品的延伸一些建议。我知道这可能是太大的问题。然而，我们真的需要一些想法，如果我们犯了这个错误的设置可能会导致我们的问题多年。我没有很多的经验，在定制和扩展现有的产品。
I am looking for some advice on how to allow easy customisation and extension of a core product on a per client basis. I know it is probably too big a question. However we really need to get some ideas as if we get the setup of this wrong it could cause us problems for years. I don't have a lot of experience in customising and extending existing products.
我们有一个核心产品，我们通常在每个客户端的基础上显出。我们最近与MVC3前端改写了该产品在C＃4。我们重构，现在有3个项目组成该解决方案：
We have a core product that we usually bespoke on a per client basis. We have recently rewritten the the product in C# 4 with an MVC3 frontend. We have refactored and now have 3 projects that compose the solution:
- 核心领域的项目（命名空间 - projectname.domain。*） - 由域模型（使用EF所），域名服务接口等（库接口）
- 域基建项目（命名空间-projectname.infrastructure。*） - 实现域服务EF上下文，仓库实现，文件上传/下载接口实现等 。
- MVC3（命名空间 - projectname.web。*） - 项目，包括控制器，的ViewModels，CSS，内容，脚本等，也有项目IOC（Ninject）处理的DI 。
此解决方案正常工作作为一个独立的产品。我们的问题是扩大并在每个客户端定制的产品。我们的客户通常要与品牌的CSS和样式给他们非常快（通常在一对夫妇签订合同的天）的核心产品版本。不过70的客户端％，则需要的定制来改变它的功能的方式。有些的定制是小如域模型，视图模型和视图等其他属性其他更显著的，需要全新的领域模型和控制器等。
This solution works fine as a standalone product. Our problem is extending and customising the product on a per client basis. Our clients usually want the core product version given to them very quickly (usually within a couple of days of signing a contract) with branded CSS and styling. However 70% of the clients then want customisations to change the way it functions. Some customisations are small such as additional properties on domain model, viewmodel and view etc. Others are more significant and require entirely new domain models and controllers etc.
一些的定制似乎对所有的客户端是有用的，所以定期我们希望它们被改变的定制，并将其添加到核心。
Some customisations appear to be useful to all clients, so periodically we would like to change them from being customisations and add them to the core.
我们是presently存储TFS源$ C $ C。要启动一个项目，我们通常是手工源复制到新的团队项目。更改命名空间，以反映客户的名字，并开始定制基本部分，然后部署到Azure上。这显然会导致一个完全复制code碱基，我敢肯定不是去了解它的正确方法。我想我们可能应该有一些提供核心功能和扩展/覆盖在需要。但是我真的不知道如何去了解这一点。
We are presently storing the source code in TFS. To start a project we usually manually copy the source into a new Team Project. Change the namespace to reflect the clients name and start customising the basic parts and then deploy to Azure. This obviously results in an entirely duplicated code base and I’m sure isn’t the right way to go about it. I think we probably should be having something that provides the core features and extends/overrides where required. However I am really not sure how to go about this.
所以我找上最好的项目配置，将允许任何建议：
So I am looking for any advice on the best project configuration that would allow:
- 的code的快速部署 - 这样容易开始新的客户端
允许品牌/细微的变化 - prevent需要复制和code的粘贴
- 尽可能多的DI尽可能使用，以保持它的松耦合
- 允许上的code的bespoking
每个客户端的基础上 - 来延长产品的核心在一个单一的能力
放置并拥有所有客户获得的功能，如果我们得到的
核心并重新部署 最新版本
任何帮助/建议是大大AP preciated。快乐添加更多的信息有人认为会有所帮助。
Any help/advice is greatly appreciated. Happy to add more information that anyone thinks will help.
推荐答案
我只是担心30或40版本（其中大部分是没有什么不同）分支中增加复杂性。
+1大问题，它更多的是经营决策，你将不得不作出：
+1 Great question, its more of a business decision you'll have to make:
做我想做一个整洁code-基地，其中维护方便，功能和修复得到迅速推广到我们所有的客户
Do I want a neat code-base where maintenance is easy and features and fixes get rolled out quickly to all our customers
还是我想要一个codeBase类的实例过多化整为零，每个微小的调整是很难的（编辑：除非你的一个ALM MVP谁可以unbrand的东西）的到合并成一个主干
or do I want a plethora of instances of one codebase split up, each with tiny tweaks that is hard ( unless your a ALM MVP who can "unbrand" things) to merged into a trunk.
我同意几乎全部的寄托@Nockawa但恕我直言，提到不设有分支机构扩展您的code结构的替代品。
I agree with almost everthing @Nockawa mentioned except IMHO dont substitute extending your code architecture with branches.
绝对使用分支/主干的策略，但你所说的分支太多就更难快速转出网站广泛的特点和阻碍项目范围内的持续集成。如果您想prevent复制/粘贴限制分支机构的数量。
Definitely use a branch/trunk strategy but as you mentioned too many branches makes it harder to quickly roll-out site wide features and hinder project-wide continuous integration. If you wish to prevent copy/pasting limit the number of branches.
在这里编码方案的要求是什么，我相信你正在寻找：
In terms of a coding solution here is what I believe you are looking for:
- 模块/插件，界面和DI是正确的目标！
- 派生自定义类，关闭基地的人（每延长客户DSL，的Assembly.Load（））
- 自定义报表解决方案（而不是新页面的大量的定制要求可能会报告）
- 以s preadsheets页面（呵呵，我知道 - 但有趣的是它的工作原理）
很好的例子是CMS的如 DotNetNuke的或Kentico 。其他想法的可以通过查看Facebook的插件架构，插件的音频和视频编辑，3D建模应用程序（如3DMAX）的和游戏，让你建立自己的水平来获得。
Great examples of the module/plugin point are CMS's such as DotNetNuke or Kentico. Other idea's could be gained by looking at Facebook's add-in architecture, plugin's for audio and video editing, 3D modeling apps (like 3DMax) and games that let you build your own levels.
最理想的解决方案将是一个管理应用程序，你可以选择你
模块（DLL的），裁缝的CSS（皮），脚本分贝，自动部署
该解决方案的Azure高达。要达致这目标插件的会赚这么
更多意义上说，codeBase的不会被拆分。此外，当一个
增强做是为了一个模块 - 你可以推广到所有的
客户端。
The ideal solution would be a admin app that you can choose your modules (DLL's), tailor the CSS (skin), script the dB, and auto-deploy the solution upto Azure. To acheive this goal plugin's would make so much more sense, the codebase wont be split up. Also when an enhancement is done to a module - you can roll it out to all your clients.
您可以轻松地做小的定制，如域模型，视图模型和视图等与用户控件，派生类和功能覆盖的附加属性。
You could easily do small customisations such as additional properties on domain model, viewmodel and view etc with user controls, derived classes and function overrides.
难道真的一般，说一个客户说我要一个标签，理货的每个人都在系统中的年龄，创建一个名为 INT SumOfField功能（串dBFieldName，串whereClause），然后为客户的网站必须结合功能的标签。然后说另外一个客户想要一个函数来计算购买产品按客户的数量，您可以重新使用它：SumOfField（product.itemCount，客户ID = 1）。
Do it really generically, say a customer says I want to a label that tally's everyone's age in the system, make a function called int SumOfField(string dBFieldName, string whereClause) and then for that customers site have a label that binds to the function. Then say another customer wants a function to count the number of product purchases by customer, you can re-use it: SumOfField("product.itemCount","CustomerID=1").
这需要全新的领域模型和控制器等将适合的插件架构更显著的变化。一个例子可能是客户需要第二地址字段，你会调整你的当前地址的用户控制是一个插件的页面，它会设置知道哪些数据库表和字段就可以实现它的接口CRUD操作
More significant changes that require entirely new domain models and controllers etc would fit the plug-in architecture. An example might be a customer needs a second address field, you would tweak your current Address user-control to be a plug-in to any page, it would have settings to know which dB table and fields it can implement its interface to CRUD operations.
如果该功能根据客户定制的30-40支
可维护性将变得很难，因为我感觉你不会
能够把它们合并起来（容易）。如果有机会的话，这将
获得真正的大你不想管理275分支机构。但是，如果其
一家专业你必须深入到了用户控制级别
每个客户端和用户不能自行设计网页，则有
Nockawa的为前端分支策略是完全
合理的。
If the functionality is customised per client in 30-40 branches maintainability will become so hard as I get the feeling you wont be able to merge them together (easily). If there is a chance this will get really big you dont want to manage 275 branches. However, if its that specialised you have to go down to the User-Control level for each client and "users cant design their own pages" then having Nockawa 's branching strategy for the front-end is perfectly reasonable.
这篇关于什么是一个很好的解决方案结构，以便在每个客户端的基础产品的轻松定制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
