0
Business Layerが、フロントエンドの外部向きのWebアプリケーションとバックエンドの内部向きのアプリケーションの両方に使用することを前提としています。外部アプリケーションには、ユーザーのログインしているID /プロファイルが常にセッションに含まれます。バックエンドアプリケーションは内部管理者専用です。リソース要求の検証、サービスまたはビジネスレイヤの責任
次のビジネスレイヤメソッドSensitiveInfoManager.GetResource（id）がある場合。外部ユーザーがこのメソッドを呼び出すと、渡されるIDが実際にそれを要求しているユーザーに属することを保証するために、何らかの検証が必要なことが想像できます。リクエストしているユーザーからリクエストしているリソースへのリンクを確立できるデータベースに適切な構造があると仮定します。また、バックエンドのWebサイト管理者は同じ方法を呼び出すことができるはずですが、ユーザーは決してリソースに縛られることはありませんが、内部管理者であることを定義するだけで、 。
問題は最大限の再利用と懸念の最善の分離によってどのように達成されますか？この検証をビジネス層に組み込み、消費者の誰かに応じて、「検証する」または「検証しない」というクラスレベルのフラグを設定しますか。または、ビジネスレイヤーの先頭にService Layerを置き、要求されたリソースの承認を得て作業しますか？バックエンドアプリケーションがBusiness Layerに直接アクセスできるサービスレイヤーを介してフロントエンドアプリケーションにチャネル要求を強制しますか？
これはサービス層として追加することです。しかし、あなたはすべての要求がそれを通過することを確かめることができますか？それをビジネスレイヤに追加しない場合。 AOP（アスペクト指向プログラミング）の完璧な候補者になるでしょう。 –
多くのビジネスロジックがフロントエンドシステムとバックエンドシステムで再利用されるのはむしろ一般的なシナリオのようです。しかし、私たちは明らかに、誰もが物事のフロントエンドのidで文を引くことを許すことはできません。 – e36M3