問題タブ [n-tier-architecture]

私は会社に入社してまだ 2 週間ですが、DotNetNuke の .NET 3.5 Team Foundation を使用してシステムの新しいプラットフォームを開始しています。私たちの「アーキテクト」は、1 つのクラス プロジェクトを使用することを提案しています。もちろん、私は「3 層」アーキテクチャー (ビジネス、データ、Web クラスのプロジェクト) を考えています。

このアーキテクチャを使用することの欠点はありますか? プロは、コードをデータから分離し、クラスオブジェクトをコードから遠ざけるなどです。

私は、新しいアプリケーションにデータ層を実装する最良の方法について同僚と「議論」している最中です。

1 つの観点は、データ層がビジネス オブジェクト (エンティティを表す独自のクラス) を認識し、そのオブジェクトをネイティブに操作できる必要があるということです。

反対の見方は、データ層はオブジェクトにとらわれず、純粋に単純なデータ型 (文字列、ブール値、日付など) を処理する必要があるというものです。

両方のアプローチが有効であることはわかりますが、私自身の見解では、前者を好むということです。そうすれば、データ ストレージ メディアが変更されても、新しいデータ レイヤーに対応するためにビジネス レイヤーを (必ずしも) 変更する必要はありません。したがって、SQL データ ストアからシリアル化された xml ファイルシステム ストアに変更するのは簡単なことです。

私の同僚の見解は、データ層がオブジェクト定義について知る必要はなく、データが適切に渡される限り、それで十分だというものです。

これが宗教戦争を引き起こす可能性のある質問の 1 つであることはわかっていますが、そのような問題にどのように取り組むかについて、コミュニティからのフィードバックをいただければ幸いです。

ティア

現在、UIからASP.Netアプリを作成しています。私はWinformsにうんざりしていて、関心の分離がより優れたものが欲しかったので、MVPアーキテクチャを実装しています。

したがって、MVPを使用すると、プレゼンターはビューによって発生したイベントを処理します。ユーザーの作成に対処するために私が用意しているコードは次のとおりです。

組み込みの.Net検証コントロールを使用してメインフォームの検証を実行しましたが、データがサービスレイヤーの基準を十分に満たしていることを確認する必要があります。

次のサービスレイヤーメッセージが表示されるとしましょう。

• メールアカウントは既に存在します（失敗）
• 入力した参照ユーザーが存在しません（失敗）
• パスワードの長さがデータストアの許容長を超えています（失敗）
• メンバーが正常に作成されました（成功）

また、UIが予測できないより多くのルールがサービスレイヤーに含まれるとしましょう。

現在、計画どおりに進まなかった場合、サービスレイヤーに例外をスローさせています。それは十分な戦略ですか？このコードはあなたたちに臭いがしますか？このようなサービスレイヤーを作成した場合、このように使用するプレゼンターを作成する必要があることに悩まされますか？リターンコードは古すぎるように思われ、ブール値は十分な情報を提供しません。

OPではなく編集：OPによって回答として投稿されたフォローアップコメントにマージ

Cheekysoft、ServiceLayerExceptionの概念が好きです。予期しない例外のためのグローバル例外モジュールがすでにあります。これらすべてのカスタム例外を面倒にすると思いますか？基本の例外クラスをキャッチするのは少し臭いと思っていましたが、そこからどのように進行するのか正確にはわかりませんでした。

tgmdbm、ラムダ式の巧妙な使用が好きです！

フォローアップしてくれたCheekysoftに感謝します。したがって、例外が処理されない場合にユーザーに別のページ（私は主にWeb開発者）が表示されることを気にしないのであれば、それが戦略になると思います。

ただし、ユーザーがエラーの原因となったデータを送信したのと同じビューでエラーメッセージを返したい場合は、プレゼンターで例外をキャッチする必要がありますか？

PresenterがServiceLayerExceptionを処理したときのCreateUserViewは次のようになります。

この種のエラーの場合は、同じビューに報告すると便利です。

とにかく、私たちは今、私の最初の質問の範囲を超えていると思います。あなたが投稿したものをいじってみます。さらに詳細が必要な場合は、新しい質問を投稿します。

LINQtoSQLがもう少し成熟したので、このテクノロジを使用してn 層ソリューションを作成するために人々が使用しているテクニックを知りたいと思います。

UI (またはサービス ファサード) から DB までのすべてのレイヤーの変更を必要とするユーザー ストーリーを実装していると仮定します。

どの方向に移動しますか？

• UIからビジネスレイヤー、リポジトリ、DBまで?
• DBからリポジトリ、ビジネスレイヤー、UIまで?
• 場合によります。（何の上に ？）

完成したばかりのプロジェクトでは、分散トランザクションを機能させる作業を行っていました。

これは、JBoss の Arjuna Transaction Manager と Spring の宣言型トランザクション境界を使用して実装しました。

リクエスト シーケンスは次のようになります。

これが意味することは、保護されたサーブレットにサービスを提供する WAR と、SLSB にサービスを提供する EAR があるということです。

SLSB には、Spring アプリケーション コンテキストをブートストラップするための静的イニシャライザ ブロックがありました。

テクノロジの混在は好きではありませんが、物理的に異なる場所に配置できるプレゼンテーション層とビジネス層の分離は好きです。

Spring を使用するときに、他の人が層を分離するために何を提案しているのか知りたいですか?

私が取り組んでいるプロジェクトでは、n 層アーキテクチャを使用しています。レイヤーは次のとおりです。

• データアクセス
• ビジネスの論理
• 事業体
• プレゼンテーション

ビジネス ロジックはデータ アクセス層を呼び出し、プレゼンテーション層はビジネス ロジック層を呼び出し、ビジネス エンティティはそれらすべてによって参照されます。

私たちのビジネス エンティティは、基本的にデータ モデル 1-1 と一致します。すべてのテーブルにクラスがあります。フレームワークが設計された当初、主従関係や親子関係を管理することは考慮されていませんでした。したがって、すべてのビジネス ロジック、データ アクセス、およびビジネス エンティティは、データベース内の 1 つのテーブルのみを参照していました。アプリケーションの開発を開始するとすぐに、オブジェクト モデルにこれらのリレーションシップがないことが深刻な問題であることが明らかになりました。

すべてのレイヤー (データベースを含む) はすべて、社内開発のコード ジェネレーターを駆動するために使用する社内のメタデータ データベースから生成されます。

問題は、エンティティの関係をロードまたは遅延ロードする最良の方法は何かということです。たとえば、アドレス テーブルに対してマスターと子の関係を持つ person クラスがあるとします。これは、Person オブジェクトの Addresses のコレクション プロパティとしてビジネス エンティティに表示されます。1 対 1 の関係がある場合、これは単一のエンティティ プロパティとして表示されます。関係オブジェクトを埋めて保存するための最良の方法は何ですか? ビジネス エンティティはビジネス ロジック レイヤーを認識していないため、プロパティが呼び出されたときに内部的に実行することはできません。

これを行うための標準的なパターンがいくつかあると確信しています。助言がありますか？

また、1 つの注意点は、DataAcess レイヤーがリフレクションを使用してエンティティを構築することです。ストアド プロシージャは、1 つのテーブルに基づいて 1 つの結果セルトを返し、リフレクションを使用して、プロパティの名前を列の名前と照合することで、ビジネス オブジェクトを設定します。したがって、結合を行うのは難しいでしょう。

私たちの顧客は、誰がオンラインで、私たちが彼らのために書いたカスタムアプリケーションを現在使用しているのか知りたいと思っています。私は彼らとそれについて話し合いました、そしてこれは正確である必要はありません、より多くのゲストが働くでしょう。

したがって、私の考えは、ユーザーアクティビティを決定するための15分の時間間隔です。これを行うためのいくつかのアイデアは次のとおりです。

1. データベースにアクセスしたり、Webページを要求したりするたびに、最後のアクティビティの日時をユーザーレコードにスタンプします。ただし、これはデータベースを大量に消費する可能性があります。

2. 私たちのソフトウェアから「オンラインリクエスト」を送信し、応答を探します。これはスケジュールされた間隔で実行でき、受信した各応答の現在の日付と時刻をユーザーレコードにスタンプします。

あなたの考えは何ですか？そして、あなたはこの状況にどのように対処しますか？

明確化

可能であれば、WindowsとWebの両方で同じアーキテクチャを使用したいと思います。複数のユーザーインターフェイスが相互作用する単一のビジネスロジックレイヤーがあります。WindowsまたはWebの場合があります。

Windowsとは、クライアントサーバーを意味します。

明確化

私はn層アーキテクチャを使用しているので、ビジネスオブジェクトはプレゼンテーション層とのすべての対話を処理します。そのプレゼンテーション層は、クライアントサーバーのWindowsアプリケーション、Webアプリケーション、Webサービスなどにフィードしている可能性があります。

それは私たちの顧客、おそらく最大で100人のユーザーのために開発されたので、トラフィックの多いアプリケーションではありません。

周りを見回すと、ルール、検証、ビジネス オブジェクト (エンティティ) などを定義するための優れたコード スニペットがいくつかありますが、優れた適切に作成されたビジネス レイヤー全体を見たことがなかったことを認めなければなりません。

嫌いなものはわかっていても、何が素晴らしいのかはわかりません。

優れた OO ビジネス レイヤー (または優れたビジネス オブジェクト) を指摘したり、ビジネス レイヤーをどのように判断したり、優れているかを教えてもらえますか?

ありがとう

クライアント向けの給与生成システムを設計しています。

対象とする組織には、会社->クラスター->ビジネスユニット（BU）->部門->従業員の階層があります。

従業員の給与は、さまざまな給与要素で構成されています。各給与コンポーネントには、計算ルール（コンポーネントを別のコンポーネントの％、または固定数または固定数の％として計算）、適格性ルール（従業員/部門がコンポーネントに適格かどうか）の3つのルールが関連付けられています。コンポーネントの最大値と最小値を制限する制約ルール。

これらのルールは編集可能であり、ユーザーエンドユーザーが編集できます。また、これらのルールはトップダウンで継承されますが、下位レベルで定義されている場合は、下位レベルのルールが優先されます。

Attendance、Leaves、Bonusesテーブルを含むデータベースがあり、これらのルールもこれらのテーブルと相互作用することになっています。

クライアントは、それぞれが個別のデータベースインスタンスをホストしている複数のクライアントの給与を生成します。それらはそれぞれ、各コンポーネントの異なる解釈を持っている可能性があり、異なるコンポーネントを持っている可能性があります。

SQL Serverのサポートのみを検討しており、給与の生成はオフラインアクティビティになります。

これらのルールを使用して個々の税コンポーネント（税控除、税控除、手当などを含む）を生成するロジックをどこに配置するかによって異なります。

一部の人々は、従業員IDを取得し、その月の給与を生成するマジックSPを提唱しています。他の人は、ロジックを個別のコンポーネントに分割して、アプリケーション層の従業員の依存データを取得し、そこでこれらのコンポーネントを計算することを望んでいます。

優先順位は次のとおりです。1。新しいクライアントに変更を迅速に適応させる機能2.長期的な保守性3.パフォーマンス

これはオフラインアクティビティになるため、ここでは1と2が3を大きく上回っています。

保守性と迅速なカスタマイズ性は非常に重要です。さまざまなクライアントにアプリケーションを展開します。クライアントAは（（0.3 *基本）+ 800）として給与コンポーネントルールを持ち、クライアントBは（0.2 *基本）+（0.1 *出席ボーナス）として持つことができます。

上記で提案されたルールはエンドユーザーによって指定され、Web UIを介してカスタマイズ可能である必要があるため、SPはここで混乱を引き起こしますか？SQLから数式を解析する必要があります。それはどれほど難しいか簡単ですか？アプリケーション層（C＃.Net）でこれを行うと、SPを使用するよりもどのような利点がありますか？

既存のシステムのアーキテクチャへの提案とポインタは非常に役立ちます。...はい、システムの他の場所でLINQtoSQLを使用しています。

よろしく、アシシュシャルマ