問題タブ [three-tier]

Microsoft.Practices.EnterpriseLibrary.Data.dllこのアセンブリとは何か、なぜこのアセンブリを使用するのかを知りたいです。

この dll の利点は何ですか?

私は 3 層アーキテクチャでプロジェクトを作成したいと考えており、SQL クエリを実行するための最良の方法は何かに興味があります。

この dll を使用するか、シンプルSqlCommandでDataAdapter. 現在、私はこの方法で作業しています:(DALファイルのコード:)

私は適切な方法で作業しているのか、Microsoft.Practices.EnterpriseLibrary.DataそれともDatabaseFactory.

多層アプリケーション構造でデフォルトを設定するための最良の方法を考えています。具体的には、特定のワークフローでネストされた関数呼び出しのセットが必要な場合、デフォルトはすべての関数で指定されていますか、それとも最上位の関数だけで指定されて渡されますか？それとも完全に他のパターンですか？

たとえば、次の3つのレイヤーを持つWebアプリについて考えてみます。

• リソースレイヤーはHTTPリクエストとレスポンスを処理し、クライアントからHTTPパラメーターを取得します
• ビジネス層は、必要な情報を決定するために必要なビジネスロジックを実行します
• データ層はデータベースにアクセスし、要求されたデータを返します。

クライアントが単一のオブジェクトを取得したいとします。この例では、そのオブジェクトを取得しPlaceます。場所オブジェクトには、type市、州、町、郡などがあります。

リソース関数は次のようになります（Django HTTPオブジェクトを使用）。

次に、他の2つは次のようになります。

このスタックのリソースレイヤーの「下」にある2つの関数も、デフォルトのタイプを「なし」にする必要がありますか？ 私の一部は、そうすることはDRYに違反すると思います。私の別の部分は、それを行う最も予測可能でモジュール式の方法は、スタック内のすべての関数がデフォルトのタイプ「賢明に」を「なし」にすることだと思います。

アプリケーションの各層（つまり、など）に例外を設けることをお勧めPresentationExceptionしますServiceException。PersistenceExceptionしかし、サービスレイヤーが追加の操作なしでDAOメソッド（永続レイヤーのメソッド）を直接呼び出すとどうなりますか。

このような：

このDAOメソッドの呼び出しをtry-catchブロックでラップし、可能な例外を次のように再スローする必要がありServiceExceptionますか？各DAOメソッドはスローする必要がありPersistenceExceptionますか？

DAL、BLL、UI レイヤーなどの 3 層アプリケーションを構築しています。DAL は EF ラッパー (UnitOfWork および Generic Repository パターン) を公開します。

BLL コンポーネントは、いくつかの基本的なビジネス ロジック ルールを持つ DAL ラッパーです。基本的に、BLL は、仮想 CRUD および検証メソッドを使用して BusinessObjectBase クラス (T は POCO クラス) を公開し、次に複数の CRUD 操作を調整する BusinessTransactionBase を公開します。

BLL コンポーネントは、一種の ObjectContext ラッパーのように見ることができます: BusinessObject = エンティティごとのビジネス ロジックを持つ ObjectSet です。BusinessTransaction = ObjectContext とその他の最小限のロジック

また、私のコンポーネントの主な目標は、さまざまなプロジェクトに一連の基本的なロジックを提供することです。今日はアセンブリを使用して MusicStore に関するアプリケーションを構築できます。明日はドキュメント管理に関するアプリケーションを構築できますが、常に基本コンポーネント (BLL) を使用したいと考えています。

簡単なスニペット:

さて、私は2つの質問があります：

1) GetBusinessObject メソッドで BusinessObjectBase を適切に構築するにはどうすればよいですか? 基本クラスから継承されたオブジェクトを構築する必要がありますが、ctor パラメーターについてはまったくわかりません。

2) IUnitOfWork が BusinessTransactionBase と BusinessObjectBase クラスの間で共有されていることをどのように保証できますか? BusinessObjectBase と BusinessTransactionBase は密接に関連しているとすでに述べたので、私はそれを強制しています。

私は多くのことをグーグルで検索しようとしましたが、答えを見つけることができませんでした.誰かが私を助けてくれることを願っていました!

私がやろうとしていること:私のwinformアプリケーションでは、コンボボックスからコンピューター名を選択する必要があります。選択すると、リストボックスにコンピューターに関するデータ(ソフトウェア名、バージョンなど)が入力されます

コンボボックスは機能していますが、他のすべてのフィールドではなく、ID のみを取得します。

データベース呼び出しを使用している私のリストビューは、次のとおりです。

私のデータベース呼び出し（動作およびテスト済み）/ clSoftwarePerPC:

* 選択は現在: select * from [table names]I've try to use the full location like this one:Software.Versionですが、これもうまくいきませんでした。ZoekId は、コンピューターを選択したコンボボックスの値です。

データベース: 私のデータベースは次のようになります: pbs.twimg.com/media/BJw-wD9CMAACZiO.jpg:large 次のようなフィールドが必要です: SoftwareOpComputer.Versie、SoftwareOpComputer.UpdateDatum、Software.Softwarenaam、Software.Ontwikkelaar。

このメソッドを使用して 1 つのテーブル (アプリケーションの他のページ) のみを使用すると機能しますが、この画面を使用して 2 つのテーブルが必要な場合は機能しません。

DTOオブジェクトをサービスレイヤーに渡すのは悪い習慣ではありませんか?

今のところ、私のサービス レイヤー メソッドは次のようになります。

DTO からビジネス エンティティ (MyEntity) への値のマッピングは、プレゼンテーション層で行われます

しかし、メソッドの署名をこれに変更したい:

その後、DTO からビジネス エンティティへのマッピングがサービス層で行われます。

編集： DTOからビジネスオブジェクトにマッピングするときに休止状態のセッションを開く必要があるため、エンティティのすべての変更が自動的にフラッシュされるため、それが必要です。

Android クライアントとやり取りする Web ベースのアプリケーションを作成したいと考えています。クライアントは EDGE/GPRS を介した信頼性の低い接続を使用しており、転送量が非常に限られているため、この HTTP プロトコルのオーバーヘッドをすべて使用して REST を使用することは避けたいと考えていました。私はすでにそのようなプロジェクトを Java で作成しました。Android クライアントは JSON をソケット経由でサーバーに送信します。アプリを 3 層アーキテクチャに移植したいと考えていました。ある種のアプリケーション サーバーで同じ結果を達成することは可能でしょうか: JBossまたはGlassfish？