什么是允许基于每个客户轻松定制产品的良好解决方案结构? [英] What is a good solution structure to allow easy customisation of a product on a per client basis?
问题描述
我正在寻求一些建议，了解如何在每个客户的基础上轻松定制和扩展核心产品.我知道这可能是一个太大的问题.然而，我们真的需要得到一些想法，好像我们设置错误一样，它可能会给我们带来多年的问题.我在定制和扩展现有产品方面没有很多经验.
我们有一个核心产品，我们通常根据每个客户定制该产品.我们最近使用 MVC3 前端在 C# 4 中重写了该产品.我们已经重构，现在有 3 个项目组成解决方案:
- 核心域项目(命名空间 - projectname.domain.*)- 由域模型(供 EF 使用)、域服务接口等(存储库接口)组成
- 域基础设施项目(命名空间 -projectname.infrastructure.*) - 实现域服务 - EF 上下文、存储库实现、文件上传/下载接口实现等.
- MVC3(命名空间 - projectname.web.*)-项目由控制器、视图模型、CSS、内容、脚本等组成.它还具有 IOC(Ninject)处理项目的 DI.
此解决方案作为独立产品运行良好.我们的问题是在每个客户的基础上扩展和定制产品.我们的客户通常希望很快(通常在签订合同后的几天内)获得带有品牌 CSS 和样式的核心产品版本.然而，70% 的客户希望通过定制来改变其运作方式.一些定制很小，例如域模型、视图模型和视图等的附加属性.其他的更重要，需要全新的域模型和控制器等.
某些定制似乎对所有客户都有用，因此我们希望定期将它们从定制更改为核心.
我们目前将源代码存储在 TFS 中.要开始一个项目，我们通常手动将源复制到一个新的团队项目中.更改命名空间以反映客户端名称并开始自定义基本部分，然后部署到 Azure.这显然会导致完全重复的代码库，我确信这不是正确的方法.我认为我们可能应该提供一些提供核心功能并在需要时扩展/覆盖的东西.但是我真的不知道该怎么做.
因此，我正在寻找有关允许的最佳项目配置的任何建议:
- 代码的快速部署——很容易启动一个新客户端允许进行品牌/细微更改
- 防止需要复制和粘贴代码
- 尽可能多地使用 DI 以保持松散耦合
- 允许定制代码每个客户的基础
- 能够在单个产品中扩展核心产品放置并让所有客户获得该功能，如果我们得到最新版本的核心并重新部署
非常感谢任何帮助/建议.很高兴添加更多任何人认为会有所帮助的信息.
我只是担心 30 或 40 个版本(其中大多数没有什么不同)分支会增加复杂性.>
<小时>+1 好问题，这更多的是您必须做出的商业决策:
我是否想要一个简洁的代码库，便于维护，并且可以快速向所有客户推出功能和修复程序
或者我是否想要拆分一个代码库的大量实例，每个实例都有很难的微小调整(除非你的 ALM MVP 可以取消品牌"的东西)合并成一个后备箱.
<小时>我同意@Nockawa 提到的几乎所有内容，但恕我直言，不要用分支代替扩展您的代码架构.
绝对使用分支/主干策略，但正如您所提到的，分支过多会使快速推出站点范围的功能变得更加困难，并阻碍项目范围的持续集成.如果您希望防止复制/粘贴，请限制分支数量.
就编码解决方案而言，我相信您正在寻找:
- 模块/插件、接口和 DI 恰到好处！
- 从基础类派生自定义类(扩展每个客户的 DSL，Assembly.Load())
- 自定义报告解决方案(许多自定义请求可能是报告而不是新页面)
- 带有电子表格的页面(嘿嘿我知道 - 但有趣的是它可以工作！)
模块/插件点的绝佳示例是 CMS，例如 DotNetNuke 或 Kentico.通过查看 Facebook 的插件架构、用于音频和视频编辑的插件、3D 建模应用程序(如 3DMax)以及可让您构建自己的关卡的游戏，您可以获得其他想法.
<块引用>理想的解决方案是一个管理应用程序，您可以选择模块 (DLL)、定制 CSS(皮肤)、编写 dB 脚本并自动部署Azure 的解决方案.为了实现这个目标，插件会这样做更有意义的是，代码库不会被拆分.还有当一个对一个模块进行了增强 - 您可以将其推广到您的所有客户.
您可以使用用户控件、派生类和函数覆盖轻松地进行小的自定义，例如域模型、视图模型和视图等的附加属性.
做一般的事情，假设一个客户说我想要一个标签来记录系统中每个人的年龄，创建一个名为 int SumOfField(string dBFieldName, string whereClause) 的函数，然后为那个客户站点有一个绑定到该功能的标签.然后说另一个客户想要一个函数来统计客户购买的产品数量，你可以重复使用它:SumOfField("product.itemCount","CustomerID=1").
需要全新域模型和控制器等的更重大更改将适合插件架构.一个例子可能是客户需要第二个地址字段，您可以将当前的地址用户控件调整为任何页面的插件，它会设置知道哪些 dB 表和字段可以实现其与 CRUD 操作的接口.
<块引用>如果在 30-40 个分支机构中为每个客户定制功能可维护性会变得如此困难，因为我觉得你不会能够将它们合并在一起(很容易).如果有机会，这将变得非常大，您不想管理 275 个分支机构.但是，如果其你必须深入到用户控制级别每个客户和用户不能设计自己的页面"然后有Nockawa对前端的分支策略很完美合理.
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.
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:
- Core domain project (namespace - projectname.domain.*) - consisting of domain models (for use by EF), domain service interfaces etc (repository interfaces)
- Domain infrastructure project (namespace -projectname.infrastructure.*) - that implements the domain service-EF Context, Repository implementation, File upload/download interface implementations etc.
- MVC3 (namespace - projectname.web.*)-project that consists of controllers, viewmodels, CSS, content,scripts etc. It also has IOC (Ninject) handling DI for the project.
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.
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:
- Rapid deployment of the code – so easy to start off a new client to allow for branding/minor changes
- Prevent the need for copying and pasting of code
- Use of as much DI as possible to keep it loosely coupled
- Allow for bespoking of the code on a per client basis
- The ability to extend the core product in a single place and have all clients gain that functionality if we get the latest version of the core and re-deploy
Any help/advice is greatly appreciated. Happy to add more information that anyone thinks will help.
I just worried that with 30 or 40 versions (most of which aren't that different) branching was adding complexity.
+1 Great question, its more of a business decision you'll have to make:
Do I want a neat code-base where maintenance is easy and features and fixes get rolled out quickly to all our customers
or do I want a plethora of instances of one codebase split up, each with tiny tweaks that is hard (EDIT: unless your a ALM MVP who can "unbrand" things) to merged into a trunk.
I agree with almost everthing @Nockawa mentioned except IMHO dont substitute extending your code architecture with branches.
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:
- Modules/Plug-ins, Interfaces and DI is right on target!
- Deriving custom classes off base ones (extending the DSL per customer, Assembly.Load())
- Custom reporting solution (instead of new pages a lot of custom requests could be reports)
- Pages with spreadsheets (hehe I know - but funnily enough it works!)
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.
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.
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").
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.
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屋！
