Entity Framework 6コードファーストのタブレットデータベースコンテキスト

Table-overlapping Database Context in Entity Framework 6 Code First

出典: link タグ:c#sqldatabaseentity-framework 更新時間:

  問題

データベースコンテキストをライブラリに入れたり、同じものに対して異なるテーブルプレフィックス/異なるデータベースを作成したりするのを避けるために、データベースコンテキストと重複するテーブルを作成する可能性はありますか?

具体的には、これはCRMシステムの例です。

データベース 

 - Pages
- Categories
- BlogEntries
- Comments
- Products
- Profiles
- Licenses
- Activations
- Invoices
- Customers

DBコンテキスト

アクティベーションサーバーコンテキストが使用する 

 - Products
- Licenses
- Activations
- Customers

顧客関係コンテキストが使用する 

 - Products
- Customers
- Invoices

フロントエンドのウェブサイトコンテキストが使用する 

 - Products
- Customers
- Invoices
- Profiles
- Pages
- Categories
- BlogEntries
- Comments

ソリューション

私がこれを行うことを考えることができる唯一の方法...

  • すべてのテーブル(incl。migrationsなど)に対処する1つのdbコンテキストを持つ1つのライブラリを作成する - >懸念の分離?
  • 関連するテーブルをプレフィックス/データベース分割で異なるコンテキストに分割する - >関連するテーブルエントリは「結びついていません」(また、重複を避けるためにguidを使用する必要があります)

  ベストアンサー

これは私がドメイン駆動型設計を避けた主な理由です。

私はちょうど1つの大きなコンテキストを持っているだろう...それはリポジトリラッパーであり、あなたのリポジトリはそれが何であるかです。すべてを1つの大きなDBに格納すると、コンテキスト/リポジトリは1つの大きなリポジトリIMOになります。

私の意見では、懸念事項の分離ではありません。コンテキストがリポジトリの懸念をラップするという意味では、それらのエンティティの周りのビジネスロジックではなく、リポジトリの懸念をラップするという意味では、データ/エンティティを永続ストレージからシリアライズおよびデシリアライズします。

私たちは約4年前にドメイン駆動型設計を実験しました。私たちは、「製品はドメイン1またはドメイン2に属していますか」についてのこれらのかなり無意味な議論を繰り返し繰り返し行っていることを発見しました。これは生産性に関する実際のドラッグであり、DDDが実際にはほとんどの現実世界のシナリオに適合しないためです。

  同じタグがついた質問を見る

c#sqldatabaseentity-framework
前へ:
次へ: