1

私は、ブログ、記事、およびビデオからボブおじさんのクリーン アーキテクチャについてもっと学ぼうとしています。

このアーキテクチャでデータベースを使用する場合、UI (Web やフォームなどのフレームワークとして) はデータベースについて何を知る必要がありますか? または、より一般的には、同じレイヤーにある 2 つ以上のピース/パーツ間でデータがどのように流れる必要がありますか?

たとえば、UI はアダプター/ゲートウェイと通信して、ビジネス エンティティと対話します。読み取り/書き込みのために、UI は、データベースにアクセスしてアダプター/ゲートウェイを渡すことができる任意のクラスを呼び出して、ビジネス エンティティと対話できることがわかります。

    public class SomeUI
    {
        public static void Main(string[] args)
        {
            SomeAdapter adapter = new SomeAdapter();
            SomeDataAccess db = new SomeDataAccess();
            db.Save(adapter);
        }
    }

    public class SomeDataAccess
    {
        public void Save(SomeAdapter adapter)
        {
            //Interact with database
        }
    }

    public class SomeAdapter
    {
        //properties
    }

記事の多くは、この記事とほとんど変わりません ( https://subvisual.co/blog/posts/20-clean-architecture )。同じレイヤーにあるピースが互いにどのように機能するかについて説明している良い記事を見つけられませんでした。したがって、それを参照する記事は受け入れられる答えになります。

これは依存関係の規則に違反しているようには見えませんが、UI とデータベースの間に依存関係を作成しているため、正しいことをしていないように感じます。私はこの概念を考えすぎているのではないかと考えています。それは、3 層アーキテクチャ (UI -> BLL -> DAL) を学習するのに苦労しているからかもしれません。

4

2 に答える 2

2

あなたが尋ねる:

このアーキテクチャでデータベースを使用する場合、UI (Web やフォームなどのフレームワークとして) はデータベースについて何を知る必要がありますか? または、より一般的には、同じレイヤーにある 2 つ以上のピース/パーツ間でデータがどのように流れる必要がありますか?

Clean ArchitectureにはUI コンポーネントという用語はありません。クリーン アーキテクチャの用語では、UIプレゼンテーションレイヤーまたは配信メカニズムであり、次のコンポーネントに分解されます。

  • UIのビジネス ルールのカプセル化を担当するビュー モデルジェネレーター (またはボブおじさんの用語を使用する場合はプレゼンター)。これは、ビジネス モデルからビュー モデルを生成するために、ビジネス モデルにアクセスする必要があります。ビジネス モデルは、その呼び出し元であるinteractorによって、 interactor 応答オブジェクト内のpresenterのメソッドに渡されます。
  • ビューのデータを保持し、イベントなどを介して間接的にビューに渡されるビューモデル。
  • ドメイン モデルとすべてのレイヤーから切り離されたダムビューは、ビュー モデルのデータを表示します。

このように分解することで、テスト容易性が向上し、SRP が向上し、アプリケーション、ドメイン、およびインフラストラクチャ レイヤーとの分離が向上します。

したがって、プレゼンテーション レイヤーは、インフラストラクチャ レイヤーについてまったく何も知らない必要があります。


ある種のWeb フォームコンポーネント/ライブラリを使用した例に混乱したのではないでしょうか? この種のコンポーネントは、ドメイン、アプリケーション、プレゼンテーションなどの複数のアーキテクチャ層に関連する相互接続された機能をそれぞれ提案します。そのため、Web フォームコンポーネントは、クリーン アーキテクチャに十分に適応するには特にデリケートです。この柔軟性の欠如により、クリーン アーキテクチャの実装にWeb フォームコンポーネントを統合する最善の方法を見つけるのにまだ苦労しています...


最後に、明確にするために、あなたは次のように言いました。

たとえば、UI はアダプター/ゲートウェイと通信して、ビジネス エンティティと対話します。読み取り/書き込みのために、UI は、データベースにアクセスしてアダプター/ゲートウェイを渡すことができる任意のクラスを呼び出して、ビジネス エンティティと対話できることがわかります。

エンティティとやり取りするのはUIの責任ではありませんが、その名前が示すように、それはinteractorの責任です ( interactor =ユースケース)。Interactorは、アプリケーションのビジネス ルールをカプセル化するためのものであり、アプリケーション層を表します。彼らは、ORM、REST APIなどのインフラストラクチャレイヤーへのアダプターであるエンティティゲートウェイを介してエンティティをCRUDできます...


編集#1

これは、クリーン アーキテクチャの構造 (および関連するコンポーネント間のデータ フロー) を表す Uncle Bob の UML クラス図です。

ここに画像の説明を入力


編集#2

クリーン アーキテクチャでの制御フローの表現は、逆になっているように思えます。上の図とボブおじさんの類推を参考にしてください。

コードを何かに依存させたくない場合は、これをpluginにします。

(別の言い方をすれば、それをコードから独立させたいコードのクライアントにします。)

クリーン アーキテクチャでは、プレゼンテーション層、またはより文脈上、配信メカニズム( Controller+ Presenter+ ViewModel+ View) をビジネス層 (通信チャネル境界の右側にあるコンポーネントで構成される)のプラグインにする必要があります。

于 2018-11-03T15:29:12.950 に答える
1

私はクリーン アーキテクチャの他の例についてさらに調査を行っています。

建築デザインソース)。

上の図から、アプリ (ビジネス エンティティとユース ケース) が配信 (外部: UI) とやり取りしているように見えます。配信は、外部 (外部: DAL) と対話するために使用されます。

配信は、アプリケーション自体の配信メカニズムを実装する場所です。配信は、アプリが外部データ ソースと統合され、ユーザーに表示される場所です。これは、最も簡単に言えば UI を意味しますが、データ ジャックなどの外部オブジェクトの具体的なバージョンを作成し、アプリ自体のアクションを呼び出すことも意味します。・レトロモカ

そのため、上部のコード例は有効であると私は信じていますが、他の誰かが答えを提供する必要があるかどうかを聞くことはまだオープンです.

于 2017-01-11T17:13:32.390 に答える