Question

请耐心等待我解释。假设我为车辆保险公司工作，我们正在努力开发一个在线门户网站，我们的客户可以购买保险单。我们只说我们提供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
)

现在来到工作流程部分

我们有一些基本的常用步骤来评估任何类型的产品。假设我们考虑到制作年份，KM旅行等形成基本评级，然后根据具体的产品类型，我们有特殊的方式来计算溢价。

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％的差异非常显着。然后再次生成保险单（实际政策文件）和发票也是一样。

所以我不知道我是否应该提出某种通用但灵活的方式来形成基类并开始继承和修改每个产品的特定行为。 OR 我应该从第一个产品中复制过去并修改2,3,4,5个产品吗？

在UI方面，我试图对我们的javascript进行组件化，这样一般只要html结构相同而id / name / class就会通过包含和启动JS来自动提供*。但问题是我需要在每个产品的任何地方复制HTML。

我不知道我是否从很高的层面上清楚地解释了我的问题。如果没有，我会根据评论更新/澄清。非常感谢你。

Answer 1

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

您可以在数据库中执行类似的操作。例如，有一个策略表，其中包含每个公共属性和一个ID的列。然后，您可以拥有包含其他字段的专家表（例如，一个用于汽车保险的表），其中一列是您的基表中的外键引用。

您可以轻松地将数据库添加到数据库中，就像它们是一个巨大的表一样，所以您没有通过很好地构造它来丢失任何内容。

Answer 2

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

首先要说的是，与前端（UI）无关紧要。并不意味着必须忽略它，但它不应该像后端一样重要。可以轻松开发任何视图引擎，并且可以使用诸如telerik和devexpress之类的许多组件来改进UI。正如我在评论中所述，有时你的前端可以改变，可能是移动，原生app等。如果你在开始时考虑前端太多，UI的改变会使你的计划工作变得浪费。

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

在设计应用程序时，首先使用接口设计。使用界面进行设计的好处将为您提供更少的耦合和更大的内聚力，并且以后可以轻松地模拟每个组件。在设计过程中保持GRASP和SOLID原则。

您可以根据需要使用任何应用程序结构，但据我所知，最模块化和最高可维护性是Dependency Injection使用Service->Repository模式。关于如何维护DI（容器等）取决于你。

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

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

最后，您可以将后端应用程序附加到WCF服务中，这样您的前端只需要调用服务即可与后端进行交互。不要忘记安全性。

我如何维护一些大部分相同的软件产品，但基于相同的代码库？

2 个答案: