web-dev-qa-db-ja.com

ビジネスロジックレイヤーをMVCから完全に分離

現在、ASP.NET MVCアプリケーションでコントローラーメソッドをリファクタリングしています。

最初に、データアクセス層を分離しました（私たちの目標は、コントローラーからLINQを完全に削除することでした）。次に、別のステップについて考えています。ビジネスロジックレイヤーを作成して、コントローラーのラインとロジックの数を減らす方法です。現在、次のようなものがあります。

public ActionResult CustomerProjects(some parameters)
{
    var collectionOfSomeType = this.CustomerRepository.GetSomeData();
    var anothercollection = this.ProjectsRepository.GetAnotherData(collectionOfSomeType);

    var viewModel = CreateSomeViewModel(anotherCollection);

    return View("Index", viewModel);
}

もちろん、これは4行のコードの例にすぎません。より大きなメソッドがいくつかあります（ただし、IMOはそれほど悪くありません）。 IoCコンテナーを介してヘルパークラスを挿入しました。より複雑なロジックがそこにあります。しかし、今はその部分も削除したいと思います。

コントローラーの前の「最後の門」となる別のレイヤーを作成する時間はありますか？最終結果は次のようになります。

public ActionResult CustomerProjects(some parameters)
{
    var viewModel = someSource.PrepareCustomerProjectsViewModel(params);

    return View("Index", viewModel);
}

どう思いますか？

designarchitecturemvcbusiness-logic
5
hugerth

私にとってここで答えるべき質問はありません。コンポーネントをできるだけ分離するよう常に努力する必要があります。

少なくとも、私が作成する新しいプロジェクトごとに、次の手順を正確に実行します。

  • 1）空のビジュアルスタジオソリューションを作成する
  • 2）MVCプロジェクトを追加します
  • 3）ビジネスレイヤーと呼ばれるクラスライブラリを追加します
  • 4）データレイヤーと呼ばれるクラスライブラリを追加します。

これを行うことにより、n層設計の優れた原則に従います。これにAOPのいくつかの形式（たとえば、シャープ後またはMVC属性）を追加して、レイヤーを横断している要素を処理します。これにより、優れた堅牢なアーキテクチャを構築できます。

データレイヤーからのRAWデータは、プレゼンテーションレイヤー（MVCアプリ）に組み込まれるべきではありません。すべてがビジネスレイヤーで結合およびフラット化されます。

ビジネスレイヤーは、それ自体とプレゼンテーションの間のDTOオブジェクトのみを処理し、データレイヤーから取り込んだ生データを使用して、アプリケーションドメインに固有のさまざまなルールも適用する必要があります。

EFコードを最初に使用し、自動マッパーなどのNu-getパッケージを使用すると、これらすべてが非常に簡単になります。

Linq、ADOまたは必要なものを使用してデータを取得するには、DALでEFを使用します。

自動マッパーを使用してそのデータをDTOに変換し、ビジネスレイヤーに渡してから、必要な作業を行ってから、最終的に自動マッパーを使用して結果のDTOをプレゼンテーションに渡します。

MVCを使用していない場合でも、WPF、Webform、Winformなどの場合でも、この戦略の採用はwin/winです。

これを正しく行うと、MVC部分は基本的にビジネスレイヤーの実行内容の頭の痛い表示になり、MVCアプリを削除してその場所に別のUIを配置する簡単さは驚くほど簡単です。

2014年11月14日更新

このスレッドに追加された最新のコメントを読んだ後、この追加部分を私の回答に追加することは十分に正当化されると感じました。

優れたアーキテクチャは、単なる「きれいなコード」以上のものです。

アーキテクチャを間違えた場合、それはクラッシュと燃焼、そして栄光の炎の中で高く飛ぶことの違いになる可能性があります。

私は1979年頃から、ITとソフトウェアの開発を何らかの形で行ってきました。その間、失敗と成功の公平な共有を見てきました。

私が最初に始めたとき、私はまだ耳の後ろに濡れていましたが、オブジェクト指向プログラミングはそれほどでもありませんでした。すべてを1つのソースファイルにまとめ、それからコンパイラーを介して実行しました。その後、GUIの種類のないリンカーを使用して助けます。

これらの時間の間に私が書いたコードのいくつかは、信じられないほど乱雑で非効率的で完全に恐ろしいものでした。成長して学んだので、なぜこの種のコードが問題を引き起こしたのか理解し始めました。ニースで読みやすいコードを書くことは確かに重要なスキルですが、表面領域も確認することも非常に重要です最小限で、優れた基準に従います。

私は長年にわたって多くの素晴らしいプロジェクトが失敗する（または、少なくとも非常に苦労する）のを目にしてきました。それがアーキテクチャ設計レベルで行われた悪い選択が原因であるたびに、それを得ることがどれほど重要であるかを強調することはできませんたった1行のコードに触れる前の設計と計画。

そして、私がこの問題に取り組んでいる間、コードジェネレーターも同じくらい危険です。コードジェネレーターがYOUが制御するテンプレートからコードを作成する場合、すばらしい方法ですが、テンプレートに依存している場合、出力の生成方法を制御できないため、問題が発生します。 Visual Studioは優れたツールであり、高速なソリューションを作成するのに最適ですが、そのボタンをクリックして何かを行う場合は、背後で何が作成されているかを正確に把握してください。

ライブラリを開発する場合、最後に行いたいのは、ソースを詳しく調べて、それがどのように機能するかを教えてもらうことです。論理的な選択を行うことで、それを設計したアーキテクトに頼り、ガイドしてくれます。これらは、優れた確かなソフトウェア職人技の知識から形成されます。

文字列や控えめな値を渡したものがクリスマスパーティーでキャンディーであるかのように信用することはありません。

誰が家を買うのをもっと信頼しますか？建築家、屋根職人、左官などの専門家チームが実装するチーム、または通りの端に住んでいる男として計画の完全なセットを調査、計画、設計するために建築家を雇った専門会社建築業で働いて、家を建てることについて少し知っていますか？

私は私の選択がどちらになるか知っています。

8
shawty

古いスレッドですが、BusinessLogicまたはManagement Layerを追加するために以下を追加したいと思います。

  • オブジェクト変換などの冗長なコードや必要なルールチェックを削除するのに役立ちます。
  • これにより、コードが再利用可能になり、次のような状況で役立ちます。WebAPIおよびアクションメソッドで同じデータをViewまたは他のアプリケーションで提供する必要があります。
  • 今後データキャッシュを適用する場合に非常に役立ちます。
  • コードをテストしやすくします。
1
Imran Javed

オブジェクトによる私の好ましい責任：

コントローラは、viewmodel/viewbagの構築を処理します。

ページのレンダリングに関連しないロジックはBLに送られます。

したがって、私は個別のレイヤーを作成せずに、コントローラー内でビューモデルを構成します。ビューモデルを構成するために作成するレイヤー、何と呼びますか？コントローラ層？

0
Andrew Hoffman