私は中規模のシステムを構築していますが、おそらく以前に直面したことがある問題に直面しています。私のビジネスレイヤーでは、そのビジネスメソッドにとって重要なプロパティのサブセットを持つビジネスオブジェクトを返します。意味のない名前のオブジェクトが多数あるか、特定のプロパティのサブセットのみが入力されているオブジェクトだけになる可能性があるため、心配しています。方法。例を挙げましょう。
ケース1
たとえば、ユーザーは都市に属しており、都市は州と国に属しており、、、User
はデータベース上の多くのフィールドを持つテーブルですが、注文のリストを含むユーザーのリストが必要なので、たとえば、重要なプロパティ()のみを使用して呼び出されるビジネスオブジェクトを作成すると、DALはデータベースからそのフィールドのみを取得します。City
State
Country
UserWithOthers
UserId, UserName, CityName, StateName, CountryName, List<Order>
ケース2
注文数のあるユーザーを返したいのですが、ビジネスオブジェクト(UserId, UserName, CityName, StateName, CountryName, OrdersCount
)の次のフィールドで終わります。たとえば、クラスを呼び出すことができます。UserWithOrderCount
私はいくつかのオプションで考えました:
- 2つのビジネスクラスを作成し、各DALメソッドに個別に入力します(このオブジェクトは単純ですが、再利用のためにカプセル化する必要がある複雑なselectクエリがメソッドに含まれる可能性があるため、リポジトリパターンがここにうまく適合しないことを考慮してください。少なくとも私は)。
User
すべてのプロパティ()を使用して1つのオブジェクトのみを作成UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>
し、各DALメソッドのサブセットのみを入力します。ただし、データベースから入力されるフィールドのサブセットを知る必要があり、セマンティックカップリングが最悪であるため、メソッドを使用する場合はセマンティックカップリングを意味します。すべてのカップリングの。List<Order>
オプション1は、後で別のビュー、およびOrdersCount
プロパティの両方で必要になった場合、うまく処理されません。- ASP.NET MVCを使用する場合、ビューに渡すにはViewModelが必要であるとのグッドプラクティスがあり、BusinnesレイヤーからViewModelを返すことを考えましたが、それは良い考えではないと思います。何かに違反しているだけでなく、私のビジネスレイヤーがWebアプリケーションではなく別のアセンブリにあるため、不可能です。
- 同じLinqクエリを何度も書きたくないのですが、NHibernateまたはEFCodeFirstを使用する場合は、オプション1に「いいね」があり、大量のスモールビジネスオブジェクトを作成する必要があります。
この状況にどのように対処しますか?これは高レベルの設計上の決定だと思います。