0

私たちのアプリのいくつかは、以下の例の複数のデータベースを使用しています - それぞれが独自の個別の DBML ファイルにあります。問題は、MVC の慣習により、それらすべてがnamespace AppName.Modelsクラス名の競合を引き起こすことです。

2 つのオプションのどちらがより適切な修正であり、その理由は次のとおりです。

1.) それらを別々の名前空間に入れる。stylecop/resharper を満足させるために、それらは独自のサブフォルダーに移動します。

  • /モデル
    • /ライブ
      • Live.dbml
      • LiveDataContext.cs
    • /Crm
      • Crm.dbml
      • CrmDataContext.cs

**しかし、コードでは、それらのすべての使用は、オブジェクトを区別する必要がLive.Customerあります。Crm.Customer

編集:これのもう1つの主な欠点は、フォルダー内のサブフォルダーを使用する専門家からのサンプルコードが他にないことModelsです。その上、Helperファイル コードの再利用のために同じ命名を維持するために - 1 つのデータベースのみを使用するアプリでさえ、.MVC でModels実行している人を見たことがない.

2.) 1 つまたは両方の DBML デザイナで、すべてのオブジェクト名にプレフィックスを追加します。これが私の現在のアプローチです。Live データベースにはCustomerとOrderオブジェクトがあり、Crm データベースにはCrmCustomerとがありCrmOrderます。それらはすべて同じ名前空間と/Modelsフォルダーにとどまります。ただし、これには 2 つの主な欠点があります。

  • 子オブジェクトにアクセスする際の接頭辞のかなりの冗長性: CrmCustomer.CrmOrders.First().CrmOrderTypeMarsha Marsha Marsha
  • 1 つのデータベースのみを使用する他のアプリでは、多くの場合、プレフィックスを省略します。そのため、コードの再利用またはHelperファイルの実行中に、多くの検索/置換を行う必要があります。Helperこれは、エラー/アクティビティ ログなど、すべてのアプリに追加されるファイルで特に顕著です。

ですから、他の専門家が 2 つの戦略のどちらを使用しているか、またはまったく別の方法を使用しているかについて、他の専門家の意見を聞きたいと思います。データベース間で少なくともいくつかの名前の競合が発生することは、かなり一般的な出来事のようです。ありがとう

テーブル名の例:

ライブ データベース:

  • お客様
  • 注文
  • 住所
  • 電話
  • ログ
  • 20 の他のテーブル

イントラネット データベース:

  • お客様
  • 注文
  • 住所
  • 電話
  • ログ
  • 20 の他のテーブル

CRM ツール データベース:

  • お客様
  • 注文
  • 住所
  • 電話
  • ログ
  • 400 その他のテーブル
4

2 に答える 2

1

私があなたの問題を正しく理解していれば、さらに 2 つの解決策が考えられます。

  1. DBML によって生成されたエンティティの名前空間を変更できます。T4 テンプレートを使用してそれらを生成すると仮定すると、*.tt ファイルを右クリックしてプロパティに移動できます。独自のカスタム、つまり一意の名前空間に設定できる名前空間プロパティがあります。

    • MyCompany.MyProject.DataModels.Live
    • MyCompany.MyProject.DataModels.Intranet
    • MyCompany.MyProject.DataModels.CRM

  2. 2 番目の同様のオプションは、各 dbml と生成されたクラスを独自のプロジェクトに含め、独自の名前空間をそれに関連付けることです。したがって、この場合、3 つの新しいプロジェクトが作成されます。

    • データライブ
    • データ.イントラネット
    • データ.CRM

    次に、プロジェクトを使用するときに、プロジェクトへの参照を追加します。

    私の意見では、これの利点は、Live、CRM、およびまったく新しいデータベースを参照する必要があるプロジェクトが明日発生する可能性が非常に高いことです。この場合、既に作成したプロジェクト (バイナリ、またはコード -- 私の好みはバイナリですが、YMMV) に依存するだけで、この 2 番目のプロジェクトのその部分は完了です。

私の意見では、クラスを装飾しないでください (オプション 2)。それを維持するのは非常に難しいでしょう。オプション 1 には本質的に問題はありません。私もそれを行いましたが、現在のソリューションのほとんどでは、再利用性要因のためにプロジェクトを作成しています。

于 2012-08-01T18:26:42.507 に答える
0

したがって、コード内に 2 つの同一のデータベースが必要になる設計には疑問があります。それはさておき、オプション1の方が良いと思います。これが私の推論です：

  1. コードはより再利用可能です。いずれかのモデルを別のプロジェクトに分離するか、モデルを削除する必要がある場合は、プレフィックスをどこからでも削除する必要はありません。これにより、きれいな分離が得られます。
  2. オプション 2 では、同様に指定する必要がありますが、これを避けているわけではありません。ただし、いずれかのクラスが 1 つの名前空間にのみアクセスする必要がある場合はusing、コードへのすべての参照ではなく、レベルでのみ指定する必要があります。両方を必要とするクラスでは、どちらの場合も接頭辞を避けていません。したがって、オプション #1 は、重要な場合にのみ有効です。
  3. 私は原則として型接頭辞を避けます。彼らは醜いです。
  4. つぶやく、つぶやく、データベースの設計
于 2012-07-23T23:25:12.370 に答える