3

ご容赦ください。説明させてください。私は自動車保険会社で働いており、顧客が保険契約を購入できるオンライン ポータルを開発しようとしているとします。自動車保険 (CI)、オートバイ保険 (MI)、トラック保険 (TI) の 3 つの保険商品を提供しているとしましょう。これらの製品の 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

0

答えようとしている。私自身もまだ学んでおり、私の発言は実際には良い場合もあれば悪い場合もあります。

最初に言うことは、フロント エンド (UI) はあまり重要ではありません。無視しなければならないという意味ではありませんが、バックエンドほど重要ではありません。どのビュー エンジンも簡単に開発でき、telek や devexpress などの多くのコンポーネントを使用して UI を改善できます。コメントで述べたように、フロント エンドをモバイルやネイティブ アプリなどに変更できる場合があります。最初にフロント エンドについて考えすぎると、UI の変更によって計画の労力が無駄になる可能性があります。

次に、ビジネス ロジックを配置する場所を選択します。データベース (sprocs) またはアプリケーションのいずれかになります。ビジネス ロジックは、数百の sproc よりも簡単に操作 (継承、ポリモーフィズム) できるため、アプリケーションに配置することをお勧めします。

アプリケーションの設計時には、最初にインターフェースを使用して設計するアプローチを使用してください。インターフェースを使用して設計することの利点は、結合が少なくなり、まとまりが増し、各コンポーネントを後で簡単にモックできることです。設計中は原則GRASPを守ってください。SOLID

任意のアプリケーション構造を自由に使用できますが、私が経験した限りでは、最もモジュール性が高く保守性が最も高いのはパターンを使用Dependency Injectionすることです。Service->RepositoryあなたのDI（コンテナなど）をどのように維持するかについてはあなた次第です。

データベースについては、大きなテーブルではなく3NFで維持することをお勧めします。その理由は、トランザクション操作のより優れた挿入/更新をサポートし、レポートのような集中的なクエリを実行しない限り、大きなテーブルは必要ありません. 今はまだ苦手な監査とロギングをお見逃しなく。

次に、適切と思われる任意のORMを使用して、データベースをアプリケーションにマップします。

最後に、バックエンド アプリケーションを WCF サービスに追加できるため、フロント エンドはサービスを呼び出してバックエンドとやり取りするだけで済みます。セキュリティもお忘れなく。

于 2013-04-09T05:57:39.557 に答える