問題タブ [3-tier]

私は設計ドキュメントを作成しており、チームのメンバーは ASP.NET WebForm から ASP.NET MVC への移行を進んで行っています。これは素晴らしいことですが、MVC が 3 層 (データ層、ビジネス層、およびプレゼンテーション層) アーキテクチャでどのように機能するかを理解するのに苦労しています。モデル、ビュー、およびコントローラーはプレゼンテーション層の一部であると言えますか? モデルはビジネス層の一部ですか?

簡単に言えば、MVC と 3 層アーキテクチャはどのように連携できるのでしょうか? 助けてくれてありがとう！

この質問をお読みいただき、ありがとうございます。

私は、毎分処理を実行する必要があるc＃で記述された3層ソリューションを設計しています。処理は、プログラムの接続されていないさまざまな部分から同時に開始する必要があります。

システム全体のタイマーを実装するための最良の方法は何ですか？それはビジネスロジック層またはUI層にあるべきですか？どの種類のタイマーが最適です。たとえば、System.Formsからのタイマー、System.Threadingからのタイマー、または？この状況の経験則はありますか？

どうもありがとう

私は現在、(非常に) 小規模なデータベース アプリケーションの研究段階にあります。

これは、システムを実行する 3 台または 4 台のクライアント マシンしかない地元の慈善団体のためのものです。クライアントが知る必要のない、常に読み通し、必要に応じて更新する）

つまり、クライアント <-> サーバー ロジック <-> データベース

私はJava自体といくつかのフレームワーク/ライブラリに精通していますが、ここでどのフレームワークが役立つかについては特に詳しくありません. 明らかに、データベースの半分に JDBC を使用しますが、クライアントとサーバー間の通信が現時点で障害になっています。たとえば、生のソケットの近くには行きたくありません (やり過ぎ、または少なくとも別のソリューションが存在する必要があります)

知っている何人かの開発者に、どの API を使用するかについての意見を聞いてみました。彼らは非常に役に立ちましたが、どこに行けばいいのかまだよくわかりません。これまでのところ、RESTful や SOAP、COBRA など、さまざまなテクノロジについて聞いてきました。SOAP は私の注意を引いた主なものです (Web だけでなく、通常のアプリケーションで使用する良い例がいくつかあるため) が、どこに行けばよいかまだわかりません。一般的なアプリケーションには特に適していないようです。このような目的のアプリ (EJB もポップアップしましたが、それを狙った憎しみがたくさんあると聞きました - これは当然のことですか?)

「仕事に最適なツール」を見つけるには、実際にそれぞれを完全に学習して「取得」する必要があるように感じます (これは明らかに非現実的です)。

これらのような API を選択する方法について (以前に使用したことがない場合)、またはいくつかの一般的な API についての情報を教えてもらえますか、それとも実際に多くの API を試してどれが適しているかを確認するだけの場合ですか?一番？

それとも、私は完全に的を外しており、明らかな短所のないこの正確な状況を目的としたフレームワークがあるのでしょうか?

助けてくれてありがとう。

編集：

それが実際に何をするかについて言及するのを完全に忘れていました: それはそれほど複雑ではありません - 慈善団体は輸送スキームを運営しているので、ドライバー、クライアント、ドライバーの走行記録などの詳細を表示および編集するために保持しています.ドライバーは、予測可能な「永遠に」続く可能性のある繰り返し (進行中の) ドライブに割り当てることができるためです。ただし、進行中のドライブの各インスタンスは、個別にキャンセルまたは編集できるため、一意である必要があります

私が 3 層に挑戦している主な理由は、慈善団体であるためです (多くの年配のボランティア コンピューター ユーザーはそれほど「精通していない」) ので、UI をかなり頻繁に更新して、バグや問題を解決している可能性があります。初心者ユーザーには非常に明確です。したがって、私の計画は、まずサーバーと DB の間のバックエンドを完全に「防弾」にすることです。次に、UI にすべての焦点を当てて、バックエンドを気にせずに開発と反復を続けることができるようにします。その一部をリモートで開発し、更新をクライアント側に集中させる方が少し簡単です)

これらすべての属性は、おそらく「Web ベースのシステムを実行してください」と叫んでいます。ここでの問題は、既に実行されているいくつかのアプリケーションとのあらゆる種類のトリッキーな統合の後であるということです。ウェブアプリ。

私は比較的小さなプロジェクトを持っており、3 層アーキテクチャを使用しています。現在、いくつかの関数を異なるデータ クラスに分割する方法を考えています。

たとえば、User クラスと Group クラスがあります。私の User クラスには User.GetGroups 関数があり、私の Group クラスには Group.GetUsers 関数があります。UserData.GetGroups または GroupData.GetGroupsForUser またはおそらく完全に別の UserGoupData クラスとして UserData クラスに最初のものを配置しますか?

私の会社では、論理 (プレゼンテーション、ビジネス、データ層) と物理レベルの両方で、ベストセラーのアプリの 1 つを 2 層から 3 層アーキテクチャに変換することを最終的に (そろそろ...) 検討しています。おそらく、変更には Delphi-Delphi-Oracle または Delphi-Java-Oracle のいずれかのアプローチを採用するでしょう。

これは、私がそこで働き始める前に長い間作成および変更されてきた、比較的古くて大きなアプリです。通常、何かを変更する必要がある場合を除いて、リファクタリングは考慮されませんでした。また、ビジネスロジックは実際の層の両方に存在します... ため息。

物理的な変化はあまり気になりませんが、論理的な変化は地獄を通過するようなものです。できるだけスムーズにするために、どの Delphi コンポーネントが 3 層モデルに適しているかを調査したいと思います。

どの代替案を使用することを検討しますか?

アプリケーションに次のレイヤーがあります。

• エンティティ
• データベース (エンティティ参照あり)
• ビジネス (データベースとエンティティの参照あり)
• ユーザー インターフェイス (ビジネスとエンティティの参照を含む)

  ---

これが私のコードの例です：

• データベース層の UserDAL クラス:

等々...

ビジネス層の UserBLL クラスでは、次のように記述します。

そしてUIで私は書きます：

さて、私は ProjectException という名前のクラスを使用して、私が作成した BLL メッセージと、OS が自動的に操作する例外メッセージを含むエラーを生成します。また、可能性のあるエラーの列挙を作成し、ここに辞書を作成して、それに関する詳細を示します。

これでいいですか？それは私にとってはうまくいきます。あなたの考えは何ですか？

以前の質問の続きとして、( https://stackoverflow.com/questions/3737848/creating-a-loosely-coupled-scalable-software-architectureを参照)

私の 3 層プロジェクトでプレゼンテーション層から BLL を抽象化したように、DAL も抽象化することを提案する人がいます。これを行う方法について何か提案はありますか? BLL と DAL の間にもファクトリが必要ですか? 私はあなたの入力が必要です..ありがとう。

与えられた:

• レイヤー プレゼンテーション、ビジネス、およびデータを備えたアーキテクチャがあります。
• ドメイン駆動設計を適用しています。
• オブジェクト指向のクエリを作成できるオブジェクト リレーショナル マッパーを使用しています (例: HQL クエリを作成できる NHibernate)。

質問：

オブジェクト指向クエリをどのレイヤーに配置する必要がありますか?

私の考え：

それらをプレゼンテーション層に入れることは通常意味がないと思います。しかし、それらをビジネスレイヤーまたはデータレイヤーのどちらに配置するかはわかりません。

例 (NHibernate):

ビジネス ロジックにメソッド GetCustomersPossiblyInterestedIn(Product p) が必要だとします。次に、顧客が p と同じカテゴリの製品を購入済みの顧客オブジェクトを選択する複雑な HQL クエリを作成できます。

引数 a)

一方で、このクエリは明らかにビジネス ロジックであると言えます。なぜなら、顧客が同じカテゴリの製品を購入したかどうかに基づいて、ある製品に興味を持っている可能性があると見なされるという決定はビジネス上の決定だからです。同様の価格で同じカテゴリの複数の製品を購入した顧客を選択することもできます。

引数 b)

一方、ビジネス レイヤーはデータ レイヤーに依存すべきではないため、ビジネス レイヤーで NHibernate を直接使用すると警鐘が鳴ります。

考えられる解決策 1)

ビジネス層で使用する独自のオブジェクト指向クエリ言語を作成し、データ層で HQL に変換します。これにより、多くのオーバーヘッドが発生すると思います。解析されたクエリ言語の代わりにクエリ オブジェクトに基づくクエリ言語を使用する場合は、多少の労力を費やす可能性がありますが、私の反論は依然として当てはまります。

考えられる解決策 2)

NHibernate が HQL や ISession などで提供できる抽象化レベルはビジネス層に適合するため、ビジネス層で NHibernate を直接使用しても問題ありません。包む必要はありません。

どう思いますか？

編集:

密接に関連する議論については、Ayende Rahien による「Repository is the new Singleton」および「The false myth of encapsulated data access in the DAL」を参照してください。

皆さん、

名前空間によってかなり n 層の ASP.NET プロジェクトがありますが、データ層、中間層、およびフロント エンドの 3 つのプロジェクトに分ける必要があります。

私はこれをやっているので...

A) それは正しいことのように思えます。

B) ASP.NET でホストされているアセンブリの単体テストを実行する際に、さまざまな問題が発生しています。

とにかく、私の質問は、設定情報をどこに保管していますか?

たとえば現在、私の中間層クラス (Linq to SQL を使用) は、新しいデータ コンテキストをインスタンス化するときに、web.config から接続文字列情報を自動的に取得します。

私のデータレイヤーが別のプロジェクトにある場合、構成情報に web.config を使用できますか?

もしそうなら、単体テスト（通常は別のアセンブリで）はどのようにsoch構成情報を提供しますか？

お時間をいただきありがとうございます！

シナリオ：プレゼンテーション層（ASP.NET）、ビジネスロジック層（dll）、データ層（dll）のシナリオがあります。後者には、特定のデータベースのテーブルとストアドプロシージャを保持するLinqTOSQL DataContextファイル（dbml）があります。 。プロジェクト間のリンクは次のとおりです。

依存関係：ビジネスロジックレイヤーにはデータレイヤーのリファレンスがありますプレゼンテーションレイヤーにはビジネスロジックレイヤーのリファレンスがあります

私の問題：問題は、データコンテキストに対応するテーブルタイプのオブジェクトを返す必要がある場合があることですが、プレゼンテーション層にはデータ層への参照がないため、テーブルオブジェクトを使用できません。 。プレゼンテーション層で直接データ層を参照することは良い習慣ですか？または、誰かがプレゼンテーション層からテーブルを実現するための最良の方法を教えてくれますか？