4

私はオープン ソース アプリケーションを構築しました。他の人が顧客固有の要求をどのように処理しているか知りたいです。アプリをシンプルに保つことは私にとって重要です。すべての人のためにすべてを作ろうとしているわけではありません。アプリは肥大化し、複雑になり、ほとんど使用できなくなる可能性があります。ただし、顧客固有のオプションがいくつかあります (すべての顧客に適用されるわけではありません)。例えば...

Server というドメイン エンティティがあるとします。UI では、顧客がサーバーのリストから選択できるようにします。ある企業では、場所 (米国、ドイツ、フランスなど) でサーバーをフィルター処理すると便利です。次のようなサーバー プロパティを追加するのは簡単です。

public class Server
{
    public Location Location { get; set; }
    // other properties here
}

私の懸念は、時間の経過とともにサーバーがプロパティで肥大化する可能性があることです。また、場所を追加しただけでも、すべての顧客がその物件を気にするわけではありません。

1 つのオプションは、ユーザー定義フィールドを許可することです。

public class Server
{
    public string UserField1 { get; set; }
    public string UserField2 { get; set; }
    public string UserField3 { get; set; }
    // etc...
    // other properties here
}

それがこれを処理する最良の方法ですか？すべてを文字列にすることで型の安全性が失われるという事実は好きではありません。人々がこのような問題を処理している他の/より良い方法はありますか? このようなもののデザインパターンさえありますか？

4

6 に答える 6

2

私の意見では、このようなものの良いデザインパターンは、データベースレベルでスキーマを使用し、次にクラスレベルで基本的な継承を使用することです。

CREATE TABLE dbo.A (
    ColumnA INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
    ColumnB VARCHAR(50),
    ColumnC INT,
    etc.
)

これで、特定の機能を必要とするクライアントができたので、別のスキーマでこのテーブルの拡張機能を作成しましょう。

CREATE TABLE CustomerA.A (
    ColumnA INT NOT NULL PRIMARY KEY,
    Location VARCHAR(50)
)

しかし今、私たちはそれを別の方法で拡張する必要がある別のクライアントを持っています：

CREATE TABLE CustomerB.B (
    ColumnA INT NOT NULL PRIMARY KEY,
    DataCenterID INT
)

フィールドは関連性がないかもしれませんが、あなたはその考えを理解しているので、ここで顧客固有のドメインモデルを構築する必要があります。

public abstract class A
{
    public int ColumnA { get; set; }
    public string ColumnB { get; set; }
    public int ColumnC { get; set; }
}

public class CustomerA_A : A
{
    public string Location { get; set; }
}

public class CustomerB_A : A
{
    public int DataCenterID { get; set; }
}

したがって、顧客Aのために何かを構築する必要がある場合は、サブクラスを構築し、顧客Bのためにサブクラスを構築します。

さて、参考までに、これは非常に動的なシステムの始まりです。欠けている部分、まだ動的ではない部分がユーザーインターフェイスであるためです。達成できる方法はたくさんありますが、この質問の範囲外です。それはあなたが考慮しなければならないことです。インターフェイスを管理する方法によって、どのサブクラスを構築するかを知る方法が決まるからです。

これがお役に立てば幸いです。

于 2012-12-05T20:45:01.060 に答える
1

初期の通常のアプローチは、この種のことのために構成XMLファイルを使用することです。ただし、クライアント固有のニーズに合わせてプログラミングするには、プログラミング方法に関する全体的な考え方が必要です。同様の質問に対するこの回答を参照してください。

于 2012-12-05T20:45:41.120 に答える
1

オプション 1:「いいえ」と言います。:-)

そして、私は（半分）冗談で言っていますが、それにはいくつかの真実があります. 多くの場合、開発者は 1 つまたは 2 つのカスタム機能を許可して、雪だるまを動かし、無限のカスタマイズを可能にします。

もちろん、これはバランスを取る必要があり、あなたはこれをある程度行っているように聞こえます. ただし、本当にアプリをシンプルに保ちたい場合は、シンプルに保ち、このようなカスタマイズを追加することは避けてください。

オプション 2:継承。

本当にカスタマイズを追加する必要がある場合は、すべての「標準」オプションを使用して基本クラスを構築し、次に顧客固有の最適化を含む顧客固有のクラスを構築する方法を学びます。

例えば：

public class Server
{
    // all standard properties here
}

次に、Joe's Pizza の場合、次のものを用意できます。

public class JoesPizzaServer : Server
{
    public Location Location { get; set; }
}

これの副次的な利点は、プレゼンテーション ビューをクライアント固有の (またはベース) モデルに基づいて作成できることです。

たとえば、MVC では、このようにビュー モデルを設定でき、顧客ごとに特定のビューを持つことができます。

たとえば、Bob's Burgers はベース モデルに独自のビューを持ちます。

@model MyApp.Server
@* implement the base form *@

Joe's Pizza のビューではカスタム モデルを使用します。

@model MyApp.JoesPizza
@* implement the base form -- a partial view -- with addtional custom fields

MVC は、このタイプのパターンを非常にうまくサポートしています。MVC (おそらく WPF または Web フォーム) を使用していない場合でも、部分的な「ビュー」ファイルを利用して同様のことを行う方法があります。

もちろん、データベースは同様の継承モデルをサポートできます (おそらくサポートする必要があります)。Entity Framework は、このようなさまざまな継承モデルもサポートしています。

于 2012-12-05T20:55:37.067 に答える
1

ここで間違っているかもしれませんが、同じコード ベースで異なるバージョンのソフトウェアを処理したいようです。これには 2 つのアプローチが考えられます。

  1. 実際には、さまざまなバージョンを定義し、クライアントごとに変更を処理します。これにより、ドメイン モデリングの観点から問題が生じることはありませんが、クライアントの要件に応じてスケーリングする必要があるサポート インフラストラクチャが必要になります。関連する質問がいくつかあります (例: this、this、およびthis )。
  2. ユーザー定義の構成として、ドメイン モデル レベルでこれを処理します。このアプローチの利点は、ソフトウェアの複数のバージョンを組み込む必要がないことですが、モデルがより一般的になり、潜在的に複雑になるという犠牲が伴います。また、さまざまなシナリオを処理するために、テストを確実に適応させる必要があります。その方向に進んでいる場合は、属性を表すオブジェクト (名前と値を使用) をモデル化し、Serverクラスが属性のコレクションを持つと見なします。このようにして、モデルは引き続き OO スタイルで要件をキャプチャします。

HTH

于 2012-12-05T20:56:26.537 に答える
1

もちろん、どの程度のカスタマイズを許可するかによって常に異なります。私たちの製品では、ユーザーがプロパティとエンティティ間の関係を使用して独自のエンティティを完全に定義できるようにするところまで行きました。基本的に、エンティティと呼ばれるすべての EntityObject は、最終的に、値のコレクションと、その中の値を記述するメタモデルへの参照で構成されます。データベースにクエリを実行し、任意のターゲット言語に翻訳可能な式を使用できる独自のクエリ言語を設計しました (ただし、現在は SQL と .net のみを処理しています)。

ゲームはそこで終わりではなく、検証ルール、アクセス許可、デフォルト値などが必須になることがすぐにわかります。もちろん、少なくともメタモデルの実行には、これらすべてに UI サポートが必要です。

そのため、エンドユーザーが実行できる調整の量に大きく依存します。あなたが説明したように、ほとんどの場合、単純なユーザーフィールドで十分だと思います。その場合、単一のフィールドを提供し、その中に JSON テキストを格納します。UI では、構造と拡張性を可能にする少なくとも半適切な UI を提供できます。

于 2012-12-05T20:51:37.913 に答える
0

Python からのアプローチは、むしろうまくいくと思いますが、それは辞書です。キーはフィールド名、値は、errrrr... 値 ;)

データベースで表現するのも簡単です。

于 2012-12-05T21:50:52.717 に答える