Val*_*roM 6 architecture sql-server asp.net web-applications
我们的产品是基于Web的课程管理系统.我们有10多个客户,未来我们可能会有更多的客户.(Asp.net,SQL Server)
目前,如果我们的客户需要额外的功能或定制的业务逻辑,我们将更改数据库架构和代码以满足需求.
(我们只有一个分支代码库和一个数据库模式)
为了使更改不会影响彼此的路由,我们使用客户端标志,该标志在Web配置文件中定义,因此这些额外的字段和业务逻辑仅应用于特定客户的系统.
if(ClientId = 'ABC')
{
//DO ABC Stuff
}
else
{
//Normal Route
}
我们的一位高级同事说,通过这种方式,像我们这样的小公司可以节省资源来支持多种资源.
但我的感觉是,这种策略使我们的代码和数据库更难维护.
那里有人遇到类似的情况？你怎么处理？
更新:如果对于SO来说这不是一个正确的问题,有人可以将此问题转移到正确的stackexchange站点吗？
Update2:你是对的.代码现在变得很臭,我肯定迟早会成为一场噩梦.我们公司正在做产品并省力,其他客户的后期产品都是基于前一个.我知道理想的方法是将@ ej-brennan开发团队分成两部分.一个团队致力于核心产品,并使其高度可定制,团队两个团队致力于为特定客户定制.但是,如果我们公司这么小,那真是一个两难的局面.:(
我认为您需要决定是否销售自定义软件,为每个客户量身定制,或者是"现成的"软件,这是一种适合所有人的(并且可能通过您提供的功能进行定制).
当你现在只有像现在这样的少数客户时,你可以逃避你正在做的事情,但我几乎可以保证,如果你继续走这条路,你的客户群增加,客户特定的定制量增加同样,你手边会有一场噩梦; 对于多个客户,我已经多次这样做了,它总是以同样的方式结束.这一切都是可以控制的,直到它不是,然后它是一个皇家的痛苦,可能会让你的生活非常困难.
如果您认为自己是一家定制公司,并希望拥有该软件和数据库的多个版本,那就没问题,只需确保您收取全部费用 - 即因为您可能需要维护多个级别的源代码因为你需要测试每个客户端的代码库,所以升级的数据库和因素将需要花费很多倍的努力.
如果您决定要成为"现成"类型的产品,那么您最好的选择是为每个客户提供定制体验的能力,而无需更改代码 - 即通过配置内置自定义功能控制工作方式的屏幕和表格 - 但每个人仍然会使用相同的底层代码和数据库.提前做更多的工作,但为您节省了大量的时间.
我也经历过你的处境，我同意这是一个困难的处境。就我而言，我正在为客户构建定制的单一产品网站。虽然每个站点都遵循类似的布局和工作流程，但每个站点都必须有足够的灵活性，以便拥有完全定制的设计、有关运输和优惠券的定制规则以及不同的商家网关和配置。
几年后，我们确实得到了一些可维护的东西。首先，我们创建了库来容纳所有通用代码，并将这些库放入一个名为 Common 的 TFS 项目中。然后，我们为每个站点（不是客户端，因为许多客户端有多个产品/站点）创建了一个新的 TFS 项目，并将适用的项目从 Common 分支到其中。接下来，我们创建了一个 VS 模板项目，其中包含站点的骨架，包括“无设计”视图、控制器及其操作方法（请记住，每个站点都有相同的基本流程）。此外，每个站点都运行自己的数据库，该数据库是从其他未使用且大部分为空的模板数据库克隆的。
由于每个站点都在自己的分支和数据库上运行，因此可以对模板安装的原始流程和设计进行修改（永远不需要合并回），而不会影响任何其他站点。对于自定义业务方法（例如运输计算），我们可以创建公共类的子类并在需要时重写。实现这一点的部分原因是将我们所有的代码转换为使用依赖注入。具体来说，每个控制器都注入了服务，每个服务都注入了存储库。商家处理也被编码到接口并注入。另外值得一提的是，这使我们能够对每个站点的所有追加销售逻辑进行硬编码（您购买了产品 X，因此我们推荐 Y），与在旧的追加销售中定义复杂的配置规则相比，这更容易创建和维护规则引擎。不知道你有没有这样的情况...
有时我们想要对通用代码本身进行更改，这通常是由特定站点的特定需求引起的。在这种情况下，我们会在该分支上进行更改，将其合并到 Common，然后在方便时将其合并到其他站点（非常适合“破坏”更改或还需要更改数据库的更改）。类似地，对于数据库更改，我们将更新模板数据库，然后编写一个小脚本来更新具有相同架构更改的其他站点数据库（仍然必须聪明且小心）。
另一个好处是，我们还创建了将在“设计”构建配置中使用/注入的模拟存储库，这使设计人员能够在应用程序中跳转并在屏幕上工作，而无需将自己提交给工作流程。它还允许他们在后端完成任何操作之前就开始在网站上工作，这对于那些需要“查看某些内容”的焦虑客户来说非常重要。
就你所说的而言，10+个客户绝对不是一个小数字。三对我来说已经够痛苦了。我们同时运行了 30 多个站点，由三名开发人员和两名设计师维护。
最后，我知道这超出了您的问题范围，而且有点自以为是，但是在设计师实际开始实施之前（以及在开发人员完成他们的工作之前）让客户对设计进行“最终”签字也为我们节省了很多成本重工。我知道没有任何设计是最终的，但提高实施端的效率可以让客户有更少的时间改变他们对批准的设计的想法。
我希望这至少能给你一些思考的方法。