如何维护几个基本相同但基于相同代码库的软件产品

本文关键字:于相同 代码 软件产品 何维护 维护 几个 | 更新日期: 2023-09-27 18:08:23

请耐心听我解释。假设我在一家车辆保险公司工作,我们正在努力开发一个在线门户网站,我们的客户可以购买保单。我们提供3种保险产品汽车保险(CI(、摩托车保险(MI(和卡车保险(TI(。我要说的是,在我们实施这些产品的方式方面,90%的产品是相似的,但在剩下的10%中,它们有很大的不同。

让我用C#作为一个例子来演示(下面的代码是一个粗略的想法,用来演示我的问题,而不是真正的代码(。

public class CarInsurancePolicy
{
    //common properties among all 3 insurance products
    public decimal MadeYear {get;set}
    public decimal PurcahsePrice {get;set}
    //specific to this particular product
    public bool HasCentralLocking {get;set}
    public DateTime SpecialDateToDoWithCar {get;set}
}
public class MotorcycleInsurancePolicy
{
    //common properties among all 3 insurance products
    public decimal MadeYear {get;set}
    public decimal PurcahsePrice {get;set}
    //specific to this particular product
    public int EngineStroke {get;set}
    public DateTime SpecialDateToDoWithMotorcycle {get;set}
}
public class TruckInsurancePolicy
{
    //common properties among all 3 insurance products
    public decimal MadeYear {get;set}
    public decimal PurcahsePrice {get;set}
    //specific to this particular product
    public decimal LoadCapacityInTons {get;set}
    public DateTime SpecialDateToDoWithTruck {get;set}
}

正如您所看到的,对于每个策略类,它们的属性基本相同,但与每种类型截然不同。现在是数据库部分。

我不知道我是否应该做这个

CREATE TABLE BaseInsurancePolicy
(
  //all common columns
)
CREATE TABLE CarInsurancePolicy
(
  //specific to this type of product
)
CREATE TABLE MotorcycleInsurancePolicy
(
  //specific to this type of product
)
CREATE TABLE TruckInsurancePolicy
(
  //specific to this type of product
)

或者我应该做这个

CREATE TABLE GiantInsurancePolicyTable
(
  //all columns and everything is NULLABLE
)

现在进入工作流程部分

我们有一些基本的通用步骤来评价任何类型的产品。假设我们将制造年份、行驶里程等因素考虑在内,形成一个基本评级,然后根据具体的产品类型,我们有特殊的方法来计算保费。

public class RatingEngingForCar
{
   //can be common step
   public decimal GetPremium() {}
   //specific for car
   private void ApplyA() {}
   private void ApplyC() {}
}
public class RatingEngingForMotorcycle
{
   //can be common step
   public decimal GetPremium() {}
   //specific for motorcycle
   private void ApplyE() {}
   private void ApplyF() {}
}
public class RatingEngingForTruck
{
   //can be common step
   public decimal GetPremium() {}
   //specific for motorcycle
   private void ApplyX() {}
   private void ApplyZ() {}
}

然后,我们的工作流程90%相似,但10%差异很大。同样,生成保险单(实际的保单文档(和发票也是如此。

因此,我不知道是否应该想出一种通用但灵活的方法来形成基类,并开始继承和修改每个产品的特定行为或者我应该只复制第一个产品的过去,并为2,3,4,5个产品进行修改吗?

在UI方面,我试图将我们的javascript组件化,这样,通常情况下,只要html结构和id/name/class相同,就会通过包含和启动JS自动提供功能。但问题是,我需要为每种产品到处复制HTML。

我不知道我是否从一个很高的层次上足够清楚地解释了我的问题。如果没有,我将根据评论进行更新/澄清。非常感谢。

如何维护几个基本相同但基于相同代码库的软件产品

在代码方面,这正是面向对象需要解决的问题。将通用功能放在基类中,并从中派生出更专业的类。

你可以在数据库中做类似的事情。例如,有一个保单表,其中每个常见属性都有一列加上一个ID。然后,您可以有包含其他字段的专业表(例如,一个汽车保险表(,其中一列是基表中的外键引用。

您可以很容易地向数据库中添加一个视图,将这些视图视为一个巨大的表来呈现,因此通过良好地构建它,您不会丢失任何东西。

尝试回答。我自己也在学习,在实践中,我的任何陈述有时都可能是好的或坏的。

首先要说的是,不要太在意前端(UI(。这并不意味着它必须被忽略,但它不应该像后端一样重要。任何视图引擎都可以很容易地开发,许多组件,如telerik和devexpress,都可以用来改进用户界面。正如我在评论中所说,有时你的前端可以更改,可能会更改为移动、本地应用程序等。如果你一开始就考虑太多前端,UI的更改可能会使你的计划工作付诸东流。

接下来,选择业务逻辑的放置位置。它可以在数据库(sprocs(中,也可以在应用程序中。我建议将业务逻辑放在应用程序中,因为它比数百个sproc更容易操作(继承、多态(。

在设计应用程序的过程中,首先使用接口设计的方法。使用接口设计的好处是减少了耦合,增加了内聚性,每个组件以后都可以很容易地进行模拟。在设计过程中要遵循GRASPSOLID的原则。

您可以根据需要使用任何应用程序结构,但根据我的经验,最模块化和最高可维护性的是使用Dependency InjectionService->Repository模式。如何维护DI(容器等(取决于您自己。

对于数据库,我建议将其维护在3NF中,而不是在大表中。原因是,它支持更好的事务操作插入/更新,并且除非执行密集的类似查询的报告,否则不需要大表。不要错过我现在还不擅长的审计和日志记录。

然后使用您认为合适的ORM将数据库映射到应用程序。

最后,您可以将后端应用程序附加到WCF服务中,这样您的前端只需要调用服务即可与后端交互。也别忘了安全。