0

MVC3とEntityFrameworkを使用してアプリケーションを開発しています。Webサーバーでホストされるプレゼンテーション層とアプリケーションサーバーのビジネス層およびデータアクセス層を使用した3層のアプローチ。オブジェクトコンテキストをプレゼンテーション層またはビジネス層に公開していません。オブジェクトコンテキストはデータアクセス層のみでラップされ、データアクセスとデータ永続性をデータアクセス層メソッドと同じ機能として公開します（つまり、データアクセスロジックは分離され、データアクセス層のみで実装されます）。ビジネスレイヤーはデータアクセスレイヤーメソッドを呼び出しており、データをプレゼンテーションレイヤーに返します。

私の懸念は、ほとんどのビジネスレイヤーメソッドはデータにアクセスするためだけのものであり、操作なしでデータアクセスレイヤーに呼び出しを転送するだけです。したがって、両方のレイヤーでコードを繰り返します。この重複を避けるために、他にもっと良いアプローチがありますか？

階層化アプローチのビジネスレイヤーにデータアクセスロジックを実装することは良い習慣ですか？

誰かが3層アーキテクチャを使用したレイヤードアプリケーションの優れた実装アプローチを提案できますか？

4

3 に答える 3

2

前に述べたように、物事を設定するための「正しい」方法はありません。私は何年にもわたって、どのアプローチを取るかを決めるのに役立ついくつかのことを見つけました。

二層

ショップに多くのデータベースプログラマーがいるストアドプロシージャが多く、データベースにビジネスロジックを配置する傾向がある場合は、2層のアプローチを採用します。この状況では、ビジネスレイヤーは通常、データレイヤーを呼び出しているだけであることがわかります。また、コードベースとページが小さい傾向があり、機能を繰り返さない場合は、2層のアプローチを使用してください。あなたは多くの時間を節約するでしょう。

3層

あなたの店がコードにたくさんのビジネスロジックを持ちたいと思っていて、そのロジックがどこでも繰り返されているなら、3層で行ってください。データレイヤーを呼び出すだけで多くのビジネスレイヤーに気付いたとしても、機能を追加すると、ビジネスレイヤーにコードを追加する方がはるかに簡単であることがわかります。また、ロジックが繰り返されるページが大量にある大規模なコードベースがある場合は、間違いなくこのアプローチを採用します。

私の仕事では、エンタープライズレベルのアプリケーションで両方が混在していることがわかりました。問題のある領域は、動的SQL（gag）が使用され、ビジネスロジックが何度も繰り返された領域です。リファクタリングをしていると、このコードを3層アーキテクチャにプルして、再利用できるので、将来的にはかなりの時間を節約できることがわかりました。

于 2012-09-15T16:32:11.753 に答える
2

ビジネス レイヤーが行っているのはデータ アクセス レイヤーへの呼び出しの委譲だけであることに気付いた場合、このビジネス レイヤーは追加の価値をもたらさないため、おそらくアプリケーションには必要ないことを強く示しています。それを取り除き、コントローラーをデータアクセスレイヤーと直接通信させることができます（もちろん抽象化を介して）-これは、そこにあるほとんどのチュートリアルがEFデータコンテキストで示していることです。

主に CRUD アクションで構成される単純なアプリケーションでは、ビジネス レイヤーは必要ない場合があります。アプリケーションが複雑になるにつれて、後で導入することを決定するかもしれませんが、特にそれらの抽象化が追加の価値をもたらさない場合は、最初からあまり多くの抽象化を行わないでください。

于 2012-09-15T15:39:10.420 に答える
0

論理的な分離のためにコードを複製することが必ずしも悪いとは思いません。これが報われる時が来る。SQL サーバーを Oracle に置き換えるとします。または、Microsoft が Linq 2.0 を発表し、一部の実装が変更されます。ビジネス層から直接データベースを呼び出した人は、DAL と BLL の両方で変更を行う必要がありますが、それを分離したことに感謝します。その価値のために。しかし、繰り返しますが、実用性、使いやすさ、利便性、そして最も重要なことは、その目的に一致することまで、正解はありません.

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

于 2012-09-15T15:19:06.937 に答える