問題タブ [n-tier-architecture]

BLLでビジネスルールのエラーを返すためのベストプラクティスは何ですか？例外を発生させてプレゼンテーション層でキャッチする必要がありますか？例外タイプ情報を保持するある種のオブジェクトを返す必要がありますか？

私の意見では、そうであり、そうではありません。

1. ロジックとデータを UI から分離しますが、それでもすべてを 1 つのポイント アプリケーションに詰め込みます。
2. コントローラはビ​​ジネス ロジックであり、ビューは UI であり、モデルは DAL であるため、実際にはそうではないと思います。これらは、同じアプリ内の単なるレイヤーになりました。

しかし、層は実際に層と呼ばれる最初または2番目の種類であると思われますか?

自分の 2 セントを追加したい人はいますか?

3つの層（名前空間を含む）があるとします。

• ユーザーインターフェイス（App.UI）-ビジネスレイヤープロセスを呼び出し、オブジェクトを使用して通信します
• ビジネスレイヤー（App.Core）-プロセスを調整し、オブジェクトを使用してDALレイヤーを使用します
• DAL（App.Data）-ストアを直接操作し、オブジェクトを永続化します

Userテーブルがあり、DALレイヤーに反映されているとしましょApp.Data.UserうApp.Data.Users。

UIには、アプリケーションユーザーを表示するビューがあります。

分離された（階層化された）アプリケーションを実際に作成するには、アプリケーションも用意する必要がApp.Core.UserありApp.Core.Users、おそらく手動で作成する必要があります。

もちろん、（私の意見では）最善の解決策は次のようになります。クラスと。を含む第4層のBusiness Objects（App.Objects）が必要です。これらのPOCOは、すべてのレイヤーで共有されます。ビジネスレイヤーはDALの使用のみが許可され、UIはBLの使用のみが許可されますが、それらはすべて共通のオブジェクトモデルに使用されます。App.Objects.UserApp.Objects.UsersApp.Objects

Asp.net MVCテンプレートは、ビューで直接DALオブジェクトを使用することを意味します。LINQ2エンティティは、POCO自体も作成しません...

では、自動コード生成を使用する場合、DALオブジェクトを使用するのか、それとも共有POCOを手動でハードコーディングするのでしょうか。最初の部分は簡単な方法のように見えますが、 DALをUIから分離していません（後でセキュリティとスケーラビリティの問題が発生する可能性があります）。2番目の部分はエラーが発生しやすく、中規模のデータベースでは非常に面倒です。

あなたは何を提案しますか？

Webページにユーザー入力を追加するときは、XSS攻撃などを防ぐために（もちろんHTMLでない限り:)エンコードする必要があります。次のようになります。

テンプレートを作成してビジネスロジックレイヤーを生成し、データがデータベースから出てすぐにUIコードに到達する前に、それを使用してすべてのエンコードを実行することを考えています。これにより、すべてがエンコードされている必要があります（Xhtml / Xml文字列を含む列は明らかに除外します）。データアクセスメソッドのオーバーロードにより、エンコードなしでデータを取得できるようになります（したがって、データを編集できます）。

これは他の誰かが使用するアプローチですか、それともばかげた考えですか？長所と短所は何ですか？

ありがとう。

Subsonic を使用して生成された素敵な DAL があります。BLL のスケルトンを生成する方法はありますか? SS レイヤーを GUI に直接接続したくありません。

私は両方の SS フォーラムをたどりましたが、誰もがSSS で生成されたレイヤーを DAL と呼んでいるようですが、彼らはそれを BLL として使用しています。

SS を使用して、BLL を最初から手動でコーディングせずに DAL 層と BLL 層を分離しましたか?

これは恥ずかしいほど基本的な n 層の質問です。

サブソニックを使用して VS2008 で DAL プロジェクトを作成しました。ウィジェット クラス、widgetcollection クラス、widgetcontroller クラスがあります。

それを参照するビジネス ロジック プロジェクトを作成しました (同じ層に配置することはできません)。特定のビジネス基準を使用して、widgetcollection を返す関数でウィジェットのコレクションを選択します。

私の質問は、GUI レイヤーがコレクションをグリッドにバインドする方法を教えてください。ウィジェットコレクションがデータグリッドの有効なデータソースであることはわかっていますが、GUI レイヤーはウィジェットとウィジェットコレクションが何であるかをどのように認識していますか? 確かに、GUI から DAL を参照する必要はありません。これは、要点全体を否定します。

C# で製品販売業者向けのアプリケーションを開発しているとします。

ディストリビューターは、次の 3 種類の取引を行います。

(1) インデント

(2) 売却

(3)在庫

私は次のようにクラスを設計しています：

これら 3 種類の情報を 3 つの別々のテーブルに保存したい場合、DA レイヤーをどのように設計すればよいでしょうか?

次のような個別のDAクラスを構築する必要があります

または単一のクラスで、演算子TransactionDAを使用して型をチェックして CRUD 操作を実行しas/isますか?

または、他に何ができますか？助言がありますか？

3 層の .NET 2.0 アプリがあります。プレゼンテーション層は中間層を参照します。中間層はデータベース層を参照します。何らかの理由で、コンパイルすると、データ層の dll がプレゼンテーション層のビンに表示されます。どうすればこれを止めることができますか?

私は現在、他の 1 人の生協の学生と一緒に、完成間近のプロジェクトに取り組んでいる生協の学期にいます。このプロジェクトは生協から生協へと受け継がれてきたため、途中で悪い慣行が取られ、最後までテストが行​​われました。テスト中に何か新しいことを学ぶために、単体テストを書きたいと思いました。

ただし、現在の形式では単体テストが不可能と思われる 3 層の密結合アプリに取り組んでいます。一晩で認識できないほどコードをリファクタリングすることで、これらの概念の知識がない他の生協の学生を捨てたくはありません。では、コードをゆっくりと単体テスト可能にするには、どのような手順を踏む必要がありますか? 最初にファクトリ パターンを実装し、先に進む前に他の生徒にそれを理解してもらう必要がありますか?

私の知識に欠陥があり、何の問題もない場合はお詫び申し上げます。私はこれが初めてです:)

最近追加されたアプリの単体テストを開始するために、テスト データベースをセットアップしました。これは 3 層設計 (プレゼンテーション層、BOL、および DAL) であり、単体テストを作成するのはこれが初めてです。

私は BOL から始めることにしました。最良の方法は、(共有文字列として渡された) ConnectionString を、新しいテスト データベースを指すものと交換することだと考えています。ただし、製品コードを変更したくありません。単体テスト中に何らかの方法でアプリをテスト データベースにリダイレクトしたいだけです。これを達成するにはどうすればよいですか？