2

私は次のように階層化されたアプリケーションを作成しています。

DB<->DAL<->BL<->サービス<->プレゼンテーション

参照されるのはそれだけです。つまり、プレゼンテーションには DAL への参照がありません。

クライアントのために作成する新しいアプリがあり、そのクライアントは私にはなじみのないものを提案しています。つまり、WRITE フローは SL を通過しますが、データベースからデータを読み取るには、DAL に直接、プレゼンテーションに linq クエリを含める必要があります。それは奇妙に思えますが、私のやり方は時代遅れであり、私のやり方と彼らの提案されたやり方は本質的に同じものだと言われています。

また、私のビジネス ロジックは通常、別のプロジェクトである BL に存在します。しかし、クライアントは、ビジネス ロジックが DTO オブジェクト自体にあることを望んでいます。

これは正常ですか？これは基本的にドメイン駆動開発か何かですか? サービス層メソッドの私の考えとは対照的に、フォームのデータを取得するための linq 呼び出しがプレゼンテーション層にあるのは奇妙だと思います。

public MyPersonObject GetPersonByPersonId(int personId)

次に、得られたものにいくつかのルールを適用する可能性のあるビジネスの同じメソッドと、Linq を持つ DAL の同じメソッドです。

4

2 に答える 2

3

クライアントはクライアントですが、CQRSを聞いたことがありますか？

クライアントは、ドメイン駆動設計の新しいアーキテクチャ方式であるCQRSの影響を受ける可能性があります。一般に、コマンドとクエリをさまざまな方法でデータベースに分離します。

しかし、クライアントが提案するアプローチでは、内部でイベントソーシングを使用しない従来のDDDとCQRSが混同されているように見えます。しかし、それでも問題はなく、通常のIMHOで、プレゼンテーション層のデータを提供するクエリは簡単で、本質的に複雑ではありません。これは、データベースからデータをクエリするだけのレポートシステムのようなもので、これにORMを使用する必要はありません。

また、私のビジネスロジックは通常、別のプロジェクトであるBLにあります。ただし、クライアントは、ビジネスロジックがDTOオブジェクト自体に含まれることを望んでいます。

ビジネスロジックはドメインエンティティに含まれている必要があります。そうでない場合は、貧血モデルのアンチパターンに違反しているようです。これもDTOには含まれていません。DTOは、ディストリビューションレイヤーとコンシューマー間のデータ転送オブジェクトの概念です。

于 2012-10-08T05:24:00.943 に答える
0

あなたが説明することは決してDDDではありません。一部の DDD 実装では、クエリとコマンド (CQRS アプローチ) に分割アーキテクチャを使用していますが、アプリケーションの適切なレイヤー化の必要性がなくなるわけではありません。

書き込みがサービス層を通過する場合、おそらくソフトウェアが少なくとも合理的な複雑さを持っていることを意味し、その間に抽象化の層を置いてプレゼンテーションを永続化から分離する必要があります。CQRS では、その層は多くの場合、クエリを受け入れ、必要なデータを含む DTO を返す Facade の形式をとります。

しかし、クライアントは、ビジネス ロジックが DTO オブジェクト自体にあることを望んでいます。

DTOはデータ転送オブジェクトの略です。DTO にはビジネス ロジックは含まれておらず、データを運ぶ以外の目的はありません。

于 2012-10-15T12:27:11.650 に答える