3

请耐心等待，让我解释一下。假设我在一家汽车保险公司工作，我们正在尝试开发一个在线门户网站，让我们的客户可以购买保险单。假设我们提供 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% 差异很大的工作流程。然后再生成保险单（实际的保单文件）和发票也是一样的。

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

在 UI 方面，我正在尝试将我们的 javascript 组件化，以便通常只要 html 结构和 id/name/class 相同，那么将通过包含和启动 JS 自动提供功能。但问题是我需要为每个产品在任何地方复制 HTML。

我不知道我是否已经从非常高的层次上把我的问题解释得足够清楚了。如果不是，我将根据评论更新/澄清。非常感谢。

4

2 回答 2

1

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

你可以在数据库中做类似的事情。例如，有一个策略表，其中包含每个常见属性的列和一个 ID。然后，您可以拥有包含其他字段的专家表（例如，一个汽车保险表），其中的一列是您的基表的外键引用。

您可以轻松地向数据库添加一个视图，将所有这些都呈现为一张巨大的表格，因此您可以通过很好地构建它并没有丢失任何东西。

于 2013-04-09T06:12:01.637 回答
0

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

首先要说的是，前端（UI）不要太在意。并不意味着它必须被忽略，但它不应该像后端那样重要。任何视图引擎都可以轻松开发，并且可以使用 Telik 和 devexpress 等许多组件来改进您的 UI。正如我在评论中所说，有时您的前端可以更改，可能会更改为移动端、本机应用程序等。如果您一开始就过多地考虑前端，那么 UI 的更改可能会使您的计划工作白费。

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

在设计您的应用程序时，请使用先设计接口的方法。使用接口设计的好处将为您提供更少的耦合和更多的内聚，并且以后可以轻松地模拟每个组件。在设计过程中坚持GRASP和SOLID原则。

您可以根据需要使用任何应用程序结构，但就我的经验而言，最模块化和最高可维护性的是使用Dependency InjectionwithService->Repository模式。关于如何维护DI（容器等）取决于您。

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

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

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

于 2013-04-09T05:57:39.557 回答