問題タブ [n-tier-architecture]

優れた開発者になるためのリソースを探す中で、n 層アプリケーションでコードを構造化する方法の良い例を探しています。

同様に...ビジネスオブジェクトは何をし、どのように見えるか、データアクセスレイヤーとどのようにインターフェースするかなど。UIはビジネスレイヤーとどのようにインターフェースし、DALと直接インターフェースしますか。

無料で入手できる、研究に値する素晴らしい例を知っていますか?

エラー処理をエレガントに実装するにはどうすればよいですか? たとえば、私のデータ アクセス レイヤーは潜在的に 2 種類のエラーをスローする可能性があります。データベース（名前が一意ではないなど）、この場合、すべてを非表示にしたくありません。

編集:

ここでのいくつかのコメントの結果として、NotAuthorizedException、DuplicateException などの派生した特殊な例外タイプを作成する必要があると考えました。

1) すべてのストアド プロシージャには、エラー メッセージを含む戻りフィールド p_error があります。DB からデータを取得したら、このフィールドをチェックして返されたエラーの種類を確認し、適切な例外をスローできるようにする必要があります。したがって、エラーの種類/エラー メッセージをどこかに保存する必要があります。つまり、最初に p_error フィールドをチェックせずに、ユーザーに正確なメッセージを (特定の時点で) どのように表示する必要があるかということです。エラーオブジェクトに戻ります。誰？

2) これは、例外の数がエラー メッセージの種類の数と等しいという悪夢に変わる可能性があります。

ここで何か不足していますか？

みんなに感謝します！

お役に立てれば幸いです。Linq to Sql を使用して階層化された Web サイトを開発しています。DBML デザイナーで memberState という新しいクラス (またはオブジェクト) を作成しました。このオブジェクトは、データベース内の実際のテーブルではありません。私は中間層にこのメソッドを持っています:

public override IEnumerable(memberState) GetMembersByState(string @state)
{
using (BulletinWizardDataContext context = DataContext)
{
IEnumerable(memberState) mems = (from m in context.Members
join ma in context.MemberAddresses
on m.UserId equals ma.UserId
join s context.States
on ma.StateId は s.StateId
に等しい s.StateName == @state
select new memberState
{
userId = m.UserID,
firstName = m.FirstName,
middleInitial = m.MiddleInitial,
lastName = m.LastName,
createDate = m.CreateDate、
modifyDate = m.ModifyDate
}).ToArray(memberState)();
メモリを返します。
}
}

結合内のテーブル (Members、States、および MemberAddresses は、データベース内の実際のテーブルです)。上記のクエリで使用できるように、オブジェクト memberStates を作成しました ( Select New memberStateに注意してください。Web ページでデータが更新されたときに、変更をメンバー テーブルに保持するにはどうすればよいですか? 私のメンバー テーブルは次の列で構成されています。 : UserId, FirstName, MiddleInitial, LastName, CreateDate, ModifyDate.変更をデータベースに保存する方法がわかりません。

ありがとう、

VS ソリューションのレイアウトに問題があります。提案をお願いします。

現在、私のソリューション レイアウトは次のプロジェクトのようになっています。

私のウェブサイト ( ) は、名前空間Foo.Webでさまざまなメソッドを呼び出します。Foo.Servicesここでの考え方は、Servicesがすべてのビジネス ロジックを処理するということです。名前Model空間は単なるPOCOオブジェクトです。Repositories名前空間は自明です。

インターフェイスを使用したコンストラクタ依存性注入は、どのレイヤーがどのコンポーネントを必要とするかという黒魔術を処理します。

問題: Windows Workflow Foundation (WWF) コードをソリューションに追加したいのですが、この WWF コードを同じ Foo.Services.dll に入れます。

これを行うには、タイプの別のプロジェクトを作成する必要がありWorkflowます。このワークフローには、Foo.Services メソッドを呼び出すアクティビティがあります。そのため、私の Web サイトでは、サービス メソッドまたはワークフロー メソッドのいずれかを呼び出して処理を行う必要があります。

Services私は、ウェブサイトが何かをするために名前空間を呼び出すだけであることを望んでいました.

結局のところ、サービスは UI とビジネス ロジック (IMO) の間の主要なインターフェイスです。私が技術的には WWF を使用しているという事実は、IUI フロントエンドでコーディングする人にとっては気にする必要はありません。

ワークフロー dll はサービス dll 内のメソッドを呼び出すため、サービス dll は循環依存のためにワークフロー内のメソッドを呼び出すことができません。

サービス dll は特別なプロジェクト タイプ (Windows ワークフロー タイプ) である必要があるため、すべてのワークフロー コードをサービス dll に移動することもできません。

だから..私は何をすべきかわからない？

消費者がビジネス用のサービス名前空間のみを参照し、WWF でこのビジネス用のものを暗示するという事実が消費者から隠されるようにするにはどうすればよいですか?

WWF プロジェクトを作成し、すべてのサービス コードをそこに移動して、古いサービス プロジェクトを破棄する必要がありますか? これを行うことは、あまり再利用可能に聞こえません。特定のパイプライン アクションの処理に WWF を使用せず、別のものを使用することにした場合はどうなりますか?

説明に役立つコードを次に示します。

ありがとうございます。

私は時代遅れの大きな州政府機関で働いています。私たちのスキルセットは時代遅れであり、予算の凍結により、新しい従業員/コンサルタントのトレーニングや雇用が妨げられています (従業員を解雇することも不可能です)。ビジネス オブジェクトの設計、設計パターンの実装、コード ライブラリとサービスの確立、単体テスト、ソース管理などはすべて、ここでは行われません。私たちはジョエルテストであなたが得ることができる限り0です. 良いニュースは、ここからしか上がれないということです！

ODBC 接続を介して Oracle データベースに直接アクセスするデスクトップ CRUD アプリケーション (C++、C#、または Java) を開発します。基本的に、GUI には SQL ステートメントとパッチワーク コードが散らばっています。データベースへの直接アクセスを防ぎ、ユーザー マシンでの Oracle クライアントの必要性を取り除くために、サービス指向の n 層アーキテクチャに移行するように言われました。

WCF は私たちが進むべき道ですか? n 層アプリケーションのウォークスルー (このようなもの) をいくつか実行しましたが、それらは簡単に実装できるように見えますが、適切なテクノロジを検討しているかどうかを理解するのに十分な知識がありません。.NET で生成された型指定された DataSet を利用することは、(多数のプロジェクトのために新しいビジネス オブジェクトをゼロから作成するのとは対照的に) 数か月または数年の作業を節約するための良い一時しのぎのように思えます。この既製のアプローチは、最初のステップとして実行可能ですか?

私の友人は、3層アプリケーションの設計と開発の経験があまりなく、このテーマに関する知識を広げたいと考えています。良いオンラインリソースやそれに関する本を教えてもらえますか？彼らが原則から始めれば素晴らしいでしょう。私はこのチュートリアルを良い出発点として考えていました。

どのようなリソースが一番好きですか？

乾杯。

こんにちは、私は階層型開発プロセスにかなり慣れていません。私は現在アプリを開発していますが、今日のテクノロジーのベスト プラクティスやアーキテクチャに関する質問について、いくつかの基本的な質問があります。サービス層として WCF を使用します。可能な限り物事を切り離そうとしていることに注意してください。LINQ TO SQL やエンティティ フレームワークが好きではない理由の 1 つである、上位層の何かが下位層の何かを知る必要はありません。

1) 層の間でデータを渡す最良の方法は何ですか? データセットまたはデータテーブルのいずれかが簡単であることはわかっていますが、この肥大化したデータ構造を階層間で渡すことが最善の解決策になるとは思いません。また、データテーブル/データセットが大きい場合、デバッグが難しくなります。おそらくPOCOオブジェクトの配列が最善の解決策になるでしょうか、それとももっと良い方法がありますか?

2) 次の質問は少しトリッキーです。多くのアプリケーションには、データのさまざまなビューがあります。複数のレポート、さまざまなデータグリッド、および 1 つまたは 2 つのグラフがある場合があります。このためにデータ層をどのように設計しますか? 各テーブルの「Get」タイプの関数を設計してから、それらをビジネスレイヤーのグリッドやレポートなどの便利なビューに結合しようとしていますか、それともビジネスレイヤーで必要な各ビューに特化した関数を持っていますか?

正直なところ、どちらのソリューションも好きではありません。ビューごとに特殊なロジックを決定する場合は、ビューごとに POCO オブジェクトを作成する必要があります (POCO オブジェクトの配列を返すと仮定します)。後でビューの 1 つにさらに列を追加する必要があると判断した場合は、既存のコードを壊すことになります (POCO のインターフェイスを変更するため)。各テーブルのビューを返し、それをビジネス レイヤーで結合しようとすると、非常に面倒になる可能性があります。TSQLには理由があります:)。また、設計によっては必要以上のデータを返す可能性があり、非効率的です。

他にもいくつか質問がありますが、それは後で取っておきます。この投稿が大きくなりたくない:)

ケージ

WCF サービスから関連データを取得し、Windows フォーム アプリケーション内で更新し、更新されたデータを WCF 経由でデータベースに永続化する n 層ソリューションを作成しました。アプリケーション、WCF サービス、およびデータベースはすべて別のマシン上にあります。

取得されるデータは、オブジェクトと子オブジェクトで構成されています...

クライアント アプリケーションによって適用される更新は、既存のコンテンツを更新するだけでなく、追加の「追跡」オブジェクトを挿入することもできます。

クライアント アプリケーションから Product オブジェクトを受け取ると、すべての更新が正しく表示されますが、すべての変更を正しく保存するには、いくつかの手順を踏まなければなりません...

確かに、これを行うためのより簡単な方法が必要ですか？

注: 午後の大半を EntityBag プロジェクトの調査に費やしましたが、これは EF RTM で動作するように更新されていないことがわかりました。特に、既存のデータは正常に更新されますが、新しいオブジェクトを混在させると例外がスローされます。