2

できるだけ詳しく説明するように努めます。SO で同様の質問があるかもしれません。私はそれらすべてを調べましたが、必要なものはありません。

だから、私は大規模なC# MVC5ベースの Web プロジェクトから始めて、できるだけ分離した方法ですべてを整理したいと考えています。データベース部分については、Telerik (以前は Open Access として知られていた)の Data Access ORM を使用します。これは、プロジェクトにMySQLを使用するためです。

これまでのところ、以下のようにすべてを整理しました。プロジェクトを分割するためのソリューション レベル フォルダーを定義しました。

**Solution**: td
- Business (Folder)
-- td.core (Project) (Contains Services and ViewModels)
-- td.interfaces (Project)
- Data (Folder)
-- td.data (Project) (Contains Database Models i.e. Telerik, Repository, Context Factory and Unit of Work class)
- Presentation (Folder)
-- td.ui (Project) (MVC5 Project, also Implemented IoC here)
- Shared (Folder)
-- td.common (Project)

一般に、MVC プロジェクトでモデルをバインドする場合、ソリューションにプロジェクトが 1 つしかない場合は、問題なく簡単に機能します。

つまり、MVC コントローラーで

var obj = new TempClass();
return View(obj.getAllUsers());

そして、対応するビューでこれを一番上で使用します

@model (model type here)

上記のように、これらすべてのレイヤーを独自のプロジェクトで分離すると。データ レイヤーは、データベースと直接通信するレイヤーであるため、Data ノードでTelerik Data Access rlinq スキーマを生成し、データベース内のテーブルのクラスも生成します (デフォルト構成)。

さて、上記の設定から、コントローラーからビジネスレイヤーを呼び出してデータを取得し、データノードと通信することになっています。

問題は、コントローラーとビューで、バインドしているモデルのデータ型/参照が必要になることです。では、自動生成されたクラスを引き続きデータ ノードに保持する必要がありますか?それとも、生成されたクラスのみを共有ノードに移動し、それらをコントローラー/ビューでバインディングに使用できますか? どれが良い練習になるでしょうか？コントローラーでデータノードを直接参照したくないので、上記のようにすべてを分離しても意味がありません。

別の簡単な質問です。REST/SOAP を介して非常に多くのサードパーティ API を統合します。これらはどのレイヤーに最適ですか?

他のアーキテクチャに関する提案や、ここで見逃しているものがある場合は、提案してください。

よろしくお願いします。

アップデート！！！

上記の更新されたアーキテクチャを参照してください。

これが私がこれまでにしたことです。

  • リポジトリ、サービス、IoC を追加しました。
  • 私の Global.asax では、サービスなどを構成する IoC を初期化しています。
  • 私のコントローラーには、ビジネスレイヤーからのサービスをパラメーターとして持つオーバーロードされたコンストラクターがあります。
  • コントローラはサービスを呼び出してデータを取得し、サービスはそのリポジトリを呼び出します。
  • タイプごとにリポジトリを手動で作成する代わりに、一般的なリポジトリ パスに従いました。
  • サード パーティの API については、データ レイヤーを使用しますが、ビジネスは後でデータがどこから来たのかわかりません。必要なものを尋ねるだけです。
  • これはすべて、必要に応じてビジネス レイヤーとデータ レイヤーの両方から参照される専用のインターフェイス プロジェクトの助けを借りて容易になりました。両方とも abc インターフェースを実装したいので、循環参照があるため、ビジネス層またはデータ層で宣言することはできません。これにより、両方の (ビジネス/データ) プロジェクトを相互に参照できなくなります。

したがって、上記の変更の助けを借りて、今やりたいことを簡単に行うことができ、すべてが思い通りに完璧に機能しています。さて、私が持っている最後の質問は

このアーキテクチャに欠陥はありますか?

4

2 に答える 2

3

別のタイプの UI の追加や永続化テクノロジの変更が簡単で、ビジネス クラスを分離して簡単にテストできるドメイン中心のアーキテクチャの場合、次のようにします。

  • 依存関係のないビジネス層。ビジネスの種類と操作を定義します。

  • データベースからビジネス タイプにマップされるデータ アクセス オブジェクト/リポジトリを含むデータ レイヤー。サードパーティの API アクセサーとアダプターをここに配置することもできます。リポジトリインターフェースが宣言されているビジネス レイヤに依存します。

  • 共有レイヤーなし。業種は、システムを流れる基本的な「通貨」です。

  • UI レイヤーは、ビジネスで宣言されたデータ アクセス インターフェイスに依存しますが、データ レイヤーには依存しません。UI をさらに分離するために、追加の UI に依存しないアプリケーション層を導入できます。

詳細については、Onion ArchitectureまたはHexagonal Architectureを参照してください。

ビジネス レイヤーと UI レイヤーが Telerik スキーマに密接に結合されているため、アーキテクチャはほとんどデータ駆動型 (または Telerik データ駆動型) です。それは何も悪いことではありませんが、コメントで述べたように、既存のデータベーススキーマからの迅速な開発、完全なドメイン分離、フレームワークにとらわれない、テスト容易性などの他のことが可能になります。

Telerik で生成されたモデルが Data モジュールまたは Shared モジュールに存在するかどうかは、そのシナリオ IMO ではほとんど違いがありません。これはアプリケーション全体の参照モデルであり、コントローラーはいずれにしてもそれに結合されます。私がアドバイスする唯一のことは、生成されたファイルを手動で移動することです。完全に自動化できる場合は、間違いなく自動化するか、ファイルをまったく移動しないでください。

于 2014-10-26T10:00:19.917 に答える
0

私はあなたの特別な技術の専門家ではありませんし、これを究極の答えとは考えていませんが、(あなたの技術に応じて) あなたが持つかもしれない可能性についていくつかのヒントを提供します:

ビジネスはデータへの排他的アクセスを持つべきです

現在、コントローラーとビューがデータベース関連のものにアクセスする必要があるのはなぜですか? ビジネス レイヤーがそのすべてを処理し、コントローラーとビューから非表示にすべきではありませんか? しかし、何らかの理由でそれが必要であると仮定しましょう。

データ層を分割する方法

生成されたクラスを手動で移動しないでください。生成設定を変更して、他の場所で部分的に生成することができます。しかし、それらを手動で選択して移動すると、メンテナンスが困難なアーキテクチャになります。

クラスの可視性を変更できる場合、よりクリーンなソリューションになります。代わりに、プロジェクトまたはフォルダーの可視性を持つクラスを生成できますか? それとも、プロジェクト設定で定義済みのパッケージまたはクラスのみをエクスポートできますか?

より多くのメンテナンスが必要な回避策は、local extensionです。データ層クラスから派生した新しいクラスを共有フォルダーに作成できます。

外部 API の構造化

後で変更しやすいように、1 つ以上の独自のプロジェクトを提供します。APIごとに1つのメインフォルダーを持つアプローチを知っています。これにより、それぞれを簡単に変更できますが、ワークスペースが散らかってしまいます。重要なプロジェクトは、1000 プロジェクトのうち 4 つだけになります。私は通常、すべての API を含む 1 つのフォルダーを好みます。したがって、API を変更するのは少し難しくなりますが、ワークスペースはクリーンなままです。あなたの決定は、API を変更、追加、削除する頻度、または単に調査する頻度という 2 つの事実に依存します。また、IDE は、ワークスペースからフォルダー/プロジェクトを「非表示」にする方法を提供していますか。

これが少し役立つことを願っています:)

于 2014-10-23T09:33:18.520 に答える