60

ばかげているように聞こえるかもしれませんが、サービス層の必要性とビジネス層との違いを理解するのは難しいと感じています。

そのため、asp.net mvc 2 を使用しており、データベースですべてのクエリを実行するデータ アクセス レイヤーがあり、次に、実行する必要があるビジネス ロジックと検証を含むビジネス レイヤーがあります。最後に、基本的にすべてのビューを持つプレゼンテーション層があります。さらに、ライブラリの一部として、いくつかのヘルパー、DTO、およびビューモデル クラスが異なるフォルダーに含まれています。しかし、私はアーキテクチャについて読み込もうとしましたが、サービス層はアーキテクチャの重要な部分であるようです。

私が理解しているのは、サービス層はすべての機能を呼び出すものだということだけです。しかし、私たちのアプリケーションでサービス層の必要性を本当に見ることができませんか? または、すでに存在している可能性がありますが、表示されません...サービスレイヤーがどのように重要であるかを例を挙げて説明できる人はいますか? 私が読んだことからかなり似ているように見えるので、ビジネス層とどのように違うのですか? 最初に必要な場合は？私たちがやろうとしているのは、可能な限り最善の方法でアプリケーションを設計することだけです.それについてのあなたの考えや経験は何ですか?

4

9 に答える 9

37

それはすべて、アプリを自己完結型の部分に分離することです。それぞれの部分は、1 つのジョブを適切に実行するための要件によって定義されます。

これにより、特殊な設計パターンとベスト プラクティスを各コンポーネントに適用できます。

たとえば、ビジネス層の仕事は、ビジネス ロジックを実装することです。完全停止。プレゼンテーション層によって消費されるように設計された API を公開することは、その「懸念事項」ではありません。

この仲介者の役割は、サービス層によって最もよく実行されます。この特殊なレイヤーを除外すると、個々のコンポーネントにさらに特殊なパターンを適用できます。

このように設計する必要はありませんが、コミュニティの蓄積された経験は、コーディングを開始する前であっても、各コンポーネントが何をすることが期待されているかを正確に知っているため、アプリケーションの開発と保守がはるかに簡単になることを示していますアプリ。

各レイヤーは、1 つのジョブを非常にうまく処理する必要があります。サービス層が実行する間を移動する役割は、そのように明確に定義された仕事の 1 つであり、それがその存在理由です。これは、車輪を再発明する必要がなく、同じ方法で何度も何度も設計される複雑さの単位です。毎回、この役割が属していないビジネスロジックでこの役割を台無しにします。サービス層をマッピング コンポーネントと考えてください。これはビジネス ロジックの外部にあり、そのクラスにもコントローラーにも属しません。

また、ビジネス ロジックから除外された結果、「ビジネス」が消費する他のアプリケーションやサービスで使用しやすい、より単純なビジネス オブジェクトが得られます。

ASP.NET MVC は、アプリケーションを特殊なコンポーネントとして記述できるようにするためのプラットフォームではありません。

コンポーネントを特殊化する方法についての理解が深まった結果、プログラムはスープとスパゲッティの原始的なボウルから、別の奇妙なものへと進化しています。シンプルな構造を使用しながら、対処できる複雑さが増しています。進化が進んでいます。人生がどうにかなるなら、これは良いものでなければならないので、ボールを転がし続けてください.

于 2010-11-05T18:37:15.147 に答える
17

建築宇宙飛行士という用語は興味深いと思うかもしれません。

重要なのは、人々がぶらぶらしているこれらの「レイヤー」のすべてに巻き込まれないようにすることです。アプリケーションに別のレイヤーがあるたびに、その中に目的がなければなりません。

たとえば、データアクセス層とビジネスロジック層の概念を1つにうまく組み合わせる人もいます。すべてのソリューションに適しているわけではありませんが、多くのソリューションで完全に機能します。プレゼンテーションとビジネスを組み合わせる人もいるかもしれません...これは多くのサークルで大したことではありませんが、繰り返しになりますが、問題のニーズには最適かもしれません。

基本的に、解決しようとしている問題によって、アプリケーションの構造が決まります。他のアプリケーションを自分のアプリケーションと統合する必要がある場合は、サービスレイヤーを追加する必要があります。これは、他の人がデータを投稿できる単純なWebフォームの形式をとるか、Webサービスでいっぱいになる可能性があります。サービスレイヤーを複数のプレゼンテーションの主要な移動場所にしたい場合もあります。

必要に応じて複雑にすることができますが、経験則として、複雑さが必要になるまで単純に保つことをお勧めします。

于 2010-11-05T18:31:49.913 に答える
15

一部の設計では、サービス層がプレゼンテーション層によって使用されていません。

サービス レイヤーは、アプリケーション内のビジネス レイヤーとデータ アクセス レイヤーを使用する他のアプリケーションによって呼び出されます。

ある意味で、サービス層はプレゼンテーション層とは別のフロントエンドです。

こちらのアーキテクチャ図を参照してください。ユーザーは、プレゼンテーション層を介してアプリケーションにアクセスします。また、外部システムはサービス層を介してアプリケーションにアクセスします。プレゼンテーション層とサービス層は、ビジネス層のアプリケーション ファサードと対話します。

これらの他の「外部システム」の例として、Web サービスと WCF サービスはサービス層を呼び出します。他の Web アプリケーションは、Web サービス呼び出しでこのアプリケーションのサービス層を呼び出すことができます。これは、両方のアプリが同じビジネス ロジックを適用していること、およびビジネス ロジックに加えられた変更が両方のアプリに反映されていることを確認する 1 つの方法です。

Chris Lively が指摘するように、レイヤーの作成に夢中になるべきではありません。アプリケーションで役立つレイヤーのみを作成することをお勧めします。私の経験では、サービス層が必要になることはあまりありませんが、ビジネス層が必要になることは非常に頻繁です。

于 2010-11-05T18:25:30.163 に答える
8

通常、サービス層は、クライアントに対してサポートする必要がある個別の操作の観点から構築されます。

たとえば、サービス層はアカウントの作成を公開する場合があります。ビジネスレイヤーは、アカウントの作成に必要なパラメーターの検証、永続化されるデータオブジェクトの構築などで構成されている場合があります。

多くの場合、サービス レイヤーは手続き型またはトランザクション スクリプト スタイルのコードを使用して、ビジネス レイヤーやロジック レイヤーを調整します。

これを知っていると、ビジネス層が実際にはサービス層でもあることに気付くかもしれません。ある時点で、あなたがこの質問をしているポイントはそのようなポイントの 1 つであり、区別はほとんどセマンティックです。

于 2010-11-05T18:50:50.977 に答える
7

私の見解では、サービス レイヤーを使用すると、プレゼンテーション レイヤーをビジネス レイヤーから分離できます。これは、ビジネス レイヤーとデータ アクセス レイヤーがデータの保持方法からユーザーを分離するのと同じです。

ビジネス レイヤー内には、「ビジネス」にとって極めて重要なものを配置します。人為的な (そしておそらくよく考えられていない例) は、製品の価格の割引が行われる場所にすることです。

サービス層により、インターフェイスをビジネスからさらに分離できます。または、変化するビジネス シナリオに応じて、他のビジネス レイヤーを交換することもできます。

ただし、すべてのアプリケーションが 1 つを必要とするわけではありません (その決定には多くの変数が関係します)。アーキテクチャが多すぎると、チームが必要としない複雑さが生じる可能性があります。

于 2010-11-05T18:25:10.727 に答える
2

単純。ビジネス ロジックをクライアントに公開するには、サービス レイヤーを使用します。自問してみてください：

ビジネス ロジックを変更する場合、サービス層を変更する必要がありますか? 答えが「常にではない」場合は、サービス層が必要です。

于 2013-02-11T23:36:24.530 に答える
2

Randy Stafford が "P of EAA" Book http://martinfowler.com/eaaCatalog/serviceLayer.htmlで Service Layer について述べていることを参照してください。

サービス層は、アプリケーションの境界 [Cockburn PloP] と、クライアント層とのインターフェイスの観点から利用可能な一連の操作を定義します。アプリケーションのビジネス ロジックをカプセル化し、トランザクションを制御し、操作の実装における応答を調整します。

于 2010-11-18T18:22:31.220 に答える
0

はい、サービス レイヤーは、ロール ベースとユーザー ベースの両方の認証に適していることにも注意してください。

于 2013-03-20T01:50:43.560 に答える