Webアプリケーションの設計におけるサービスレイヤーとビジネスレイヤーの違い
これはばかげているように聞こえるかもしれませんが、サービスレイヤーの必要性とビジネスレイヤーとの違いを理解するのは難しいと感じています。
したがって、asp.net mvc 2を使用しており、データベースへのすべてのクエリを実行するデータアクセスレイヤーがあり、次に、実行する必要があるビジネスロジックと検証を持つビジネスレイヤーがあります。最後に、基本的にすべてのビューを持つプレゼンテーション層があります。さらに、ライブラリーの一部として、いくつかのヘルパー、DTO、およびビューモデルクラスを別のフォルダーに配置しています。しかし、私はアーキテクチャについて読んでみましたが、サービス層はアーキテクチャの重要な部分のようです。
私が理解しているのは、サービス層がすべての関数を呼び出すものであることです。しかし、アプリケーションでのサービスレイヤーの必要性は本当にわかりませんか？または、すでに存在しているのに見えない場合があります...サービスレイヤーの重要性を例を挙げて誰でも説明できますか？私が読んだものとかなり似ているため、ビジネスレイヤーとはどのように違うのですか？それが最初に必要な場合はどうですか？私たちがやろうとしているのは、あなたの考えや経験について、可能な限り最善の方法でアプリケーションを設計することです。
それはすべて、アプリを自己完結型のピースに分離することに関するものであり、それぞれが1つのジョブを本当にうまく実行するための要件によって定義されます。
これにより、各コンポーネントに特別な設計パターンとベストプラクティスを適用できます。
たとえば、ビジネスレイヤーの仕事は、ビジネスロジックを実装することです。フルストップ。プレゼンテーション層で使用されるように設計されたAPIを公開することは、その「懸念」ではありません。
仲介者のこの役割は、サービス層によって最もよく実行されます。この特殊化されたレイヤーを除外すると、より個別化されたパターンを個々のコンポーネントに適用できます。
このように設計する必要はありませんが、コミュニティの蓄積された経験は、コーディングを開始する前でも、各コンポーネントが何を期待されているかを正確に把握しているため、開発と保守がはるかに容易なアプリケーションになることを示していますアプリ。
各層は1つの仕事を本当にうまくやるべきです。サービスレイヤーが実行する役割の間の役割は、そのような明確に定義されたジョブの1つであり、それがその存在の理由です。ホイールを再発明する必要はなく、同じ方法で何度も何度も設計される複雑さの単位です。毎回、このロールが属していないビジネスロジックでこのロールを壊します。サービス層はマッピングコンポーネントと考えてください。これはビジネスロジックの外部にあり、そのクラスにもコントローラーにも属していません。
また、ビジネスロジックから除外された結果、 "ビジネス"が使用する他のアプリケーションやサービスでより簡単に使用できる、よりシンプルなビジネスオブジェクトが得られます。
ASP.NET MVCは、アプリを特殊なコンポーネントとして作成できるようにするためのプラットフォームではありません。
コンポーネントをどのように特殊化するかについてのこの理解の高まりの結果として、プログラムは、スープとスパゲッティの原始的なボウルから、何か別の奇妙なものへと進化しています。単純な構造を使用しながら、対処できる複雑さが増しています。進化が進んでいます。人生に行きたいことがあれば、これは良いことなので、ボールを転がし続けます。
Architecture Astronaut という用語が興味深いかもしれません。
重要なのは、人々がむちゃくちゃになっているこれらの「レイヤー」のすべてに巻き込まれないことです。アプリケーションに別のレイヤーがあるたびに、その中に目的がなければなりません。
たとえば、一部の人々は、データアクセスレイヤーとビジネスロジックレイヤーの概念を1つにうまく組み合わせています。すべてのソリューションに適しているわけではありませんが、多くのソリューションで完全に機能します。一部の人々は、プレゼンテーションとビジネスを組み合わせることさえあるかもしれません...これは多くのサークルのメジャーノーノーですが、再び、問題のニーズにぴったりかもしれません。
基本的に、解決しようとしている問題は、アプリケーションの構造を決定する必要があります。他のアプリケーションを自分のアプリケーションと統合する必要がある場合は、サービスレイヤーを追加する必要があります。これは、他のユーザーがデータを投稿できる単純なWebフォームの形式をとるか、Webサービスがいっぱいになる可能性があります。サービスレイヤーを複数のプレゼンテーションの主要な移動先にする場合もあります。
必要に応じて複雑にすることもできますが、経験則としては、複雑さが必要になるまで単純にしておくことをお勧めします。
一部のデザインでは、サービスレイヤーはプレゼンテーションレイヤーで使用されません。
サービスレイヤーは、アプリケーションのビジネスレイヤーとデータアクセスレイヤーを使用する他のアプリケーションによって呼び出されます。
ある意味で、サービス層はプレゼンテーション層とは別のフロントエンドです。
アーキテクチャ図 をご覧ください。ユーザーはプレゼンテーション層を介してアプリケーションにアクセスします。また、外部システムはサービスレイヤーを介してアプリケーションにアクセスします。プレゼンテーション層とサービス層は、ビジネス層のアプリケーションファサードと通信します。
他の「外部システム」の例として、WebサービスとWCFサービスはサービスレイヤーを呼び出します。他のWebアプリケーションは、Webサービス呼び出しでこのアプリケーションのサービスレイヤーを呼び出すことができます。これは、両方のアプリが同じビジネスロジックを適用し、ビジネスロジックに加えられた変更が両方のアプリに反映されるようにするための1つの方法です。
Chris Livelyが指摘するように、レイヤーの作成に夢中になってはいけません。アプリケーションで役立つレイヤーのみを作成することをお勧めします。私の経験では、サービス層の必要性は頻繁ではありませんが、ビジネス層の必要性は非常に頻繁です。
サービス層は通常、クライアントでサポートする必要のある個別の操作に関して構築されます。
たとえば、サービスレイヤーはアカウントの作成を公開します。一方、ビジネスレイヤーは、アカウントの作成、永続化するデータオブジェクトの構築などに必要なパラメーターの検証で構成されます。
多くの場合、サービスレイヤーは、手続き型またはトランザクションスクリプトスタイルのコードを使用して、ビジネスレイヤーやロジックレイヤーを調整します。
これを知っていると、yourビジネスレイヤー本当にサービスレイヤーでもあることに気付くでしょう。ある時点で、この質問をしているポイントがそのようなポイントの1つであるという点で、区別は主に意味論的です。
私の観点から見ると、ビジネス層とデータアクセス層がデータの永続化方法からユーザーを分離するのと同じように、サービスレイヤーを使用すると、プレゼンテーションレイヤーをビジネスレイヤーから分離できます。
ビジネス層の内部には、「ビジネス」にとって極めて重要なものを配置します。工夫された（そしておそらく不十分に考案された例）とは、製品の割引価格が発生する場所となることです。
サービス層を使用すると、インターフェイスをビジネスからさらに分離できます。または、ビジネスの変化するシナリオに応じて、他のビジネスレイヤーを交換することもできます。
ただし、すべてのアプリケーションが1つを必要とするわけではありません（その決定には多くの変数が含まれます）。アーキテクチャが多すぎると、チームが必要としない複雑さをもたらす可能性があります。
ランディスタッフォードが「P of EAA」の本でサービスレイヤーについて述べていることを確認してください http://martinfowler.com/eaaCatalog/serviceLayer.html
サービス層は、アプリケーションの境界[Cockburn PloP]と、クライアント層とのインターフェースの観点から使用可能な一連の操作を定義します。 アプリケーションのビジネスロジックをカプセル化し、その操作の実装でトランザクションを制御し、応答を調整します。
シンプル。ビジネスロジックをクライアントに公開するには、サービスレイヤーを使用します。自問してみてください：
ビジネスロジックを変更する場合、サービスレイヤーを変更する必要がありますか？答えが「常に」ではない場合、サービス層が必要です。
このスレッドは古いことを知っていますが、サービスレイヤーで行った便利なことの1つはトランザクションを処理することです（ビジネスレイヤーはロールバックや操作の順序などの処理方法を知っている必要はありません）。
私がやったもう1つのことは、ドメインエンティティとDTOの間の変換に使用されました。ビジネスレイヤーはドメインモデルを処理しますが、データをDTOの形式でプレゼンテーションレイヤーに渡しました（場合によっては、さまざまな理由でドメインモデル全体をプレゼンテーションレイヤーに公開することが現実的ではありませんでした）。そのため、サービス層はこのマッピングを処理します。
結局のところ、私はビジネスレイヤーがより細かいように見えますが、サービスレイヤーはBLLで複数の操作を呼び出し、1つのサービスコール内で呼び出しを注文できるという点で、より粗い場合があります。
はい、私はまた、サービス層がロールベースとユーザーベースの両方の認証に適した場所であることにも注意します。