問題タブ [n-layer]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
wcf - N層アーキテクチャ
システムを一から設計・実装しなければならない状況です。アーキテクチャについていくつか質問があるので、コメントや考えをお願いします。
プロジェクトに関するクイック情報: データ中心の Web アプリケーションです。
アプリケーションは、MS SQL SERVER 2008 データベースを使用する Microsoft .NET Framework 4.0 上に構築されます。
要件:
- 豊富な UI と堅牢性
- マルチデバイスのサポート (すべてのブラウザーとすべてのデバイス)
- 疎結合
以下は、私が構築したアーキテクチャ図です。
アーキテクチャのブリーフィング
- プレゼンテーション層 : HTML5/ASP.NET MVC + JQuery (最初のバージョンではマルチデバイス対応の Web アプリケーション)
- 分散サービス : WCF (XML/JSON/JSONP)
- Domain Layer(Business Layer) : すべてのビジネスロジック
- データの永続性 (DAL レイヤー) : データベース ファースト アプローチの Entity Framework 4.0。POCO エンティティは、T4 テンプレートを使用して生成および分離されます
- インフラストラクチャ層: POCO エンティティ、例外処理、ロギングなどの共通ライブラリが含まれています。
私の懸念:
- アプリケーションは疎結合で構築されるため、将来的にビジネス要件が増大した場合、アーキテクチャに影響を与えることなく新しいモジュールを簡単にプラグインできます。そこで、IoC と DI と共にリポジトリ パターンを使用することを考えました (Unity/Ninject/Sprint.NET またはその他のいずれでもかまいません)。
- XML と JSON の両方をサポートする WCF
- IoC & DI を配置する分散サービス層
- Enterprise Library 5.0 を使用した例外処理とログ記録
貴重なコメントや提案を探しています。私が何か間違ったことをしている場合は、私を正しい方向に向けてください。
entity-framework-4.1 - ユニティおよびライフタイム管理構成 - 常に一時的なライフタイム マネージャー
Unity で構成エラーが発生しました。http://unitymvc3.codeplex.com/を実装しようとしていますが、このため、現在行き詰まっています:
私のユニティ構成では、次の設定があります。
しかし、団結を作成する時点で、(私の簡単なコードはここにあります:)
を持っている登録「IManDbContext」を除いて、すべてがうまく設定されていますがLifetimeManagerType = {Name = "TransientLifetimeManager" FullName = "Microsoft.Practices.Unity.TransientLifetimeManager"}
、そうでなければなりませんhierarchical lifetime manager
Unityに(コードではなく構成で)階層的なライフタイムマネージャーが必要であることを伝える方法はありますか?ヒントをありがとう。
c# - クラス ライブラリの .net 参照 Web
n 層のアプリ/サイトを作成しています。Common クラス ライブラリで NetSqlAzMan Web 参照を呼び出す必要がありますが、それはクラス ライブラリにインポートできず、Web サイト タイプのプロジェクトにのみインポートできます。これを回避する 1 つの方法は、共通レイヤーをサイトにすることですが、それは正しくないようです。それを適切に実装する方法は?私はVS2010 Proを使用しています
entity-framework - サービス層、リポジトリ層、Entity Framework
ASP.Net MVC アプリケーション、モバイル アプリケーションなどで同じレイヤーを使用するために、Entity Framework (POCO エンティティ) を使用してレイヤード アーキテクチャ (すべてのレイヤーが同じマシン上にある) を設計しています。また、テスト容易性を維持するために...
UI レイヤー > サービス レイヤー > リポジトリ レイヤー > エンティティ フレームワーク > データベースを配置し、依存関係の挿入、レイヤーの抽象化、関心の分離を行います。
2 つのメソッドがあるとします (Customer、Order はエンティティ クラスです)。これらのメソッドをどのレイヤーに配置する必要がありますか?:
- public IList GetOrdersByCustomerId(int CustomerId) LINQ クエリを含みます。
(リポジトリ層、またはサービス層?) - public void RequestAnOrderAndStartTheShipmentProcess(Customer CustomerEntity, Order OrderEntity) orderRepository.Add(OrderEntity)、shipmentRepository.Add(ShipmentEntity) などの挿入操作を行います...
(別のビジネス ロジック層、またはサービス層?)
- public IList GetOrdersByCustomerId(int CustomerId) LINQ クエリを含みます。
IOrderService インターフェイスと、依存性注入用の "OrderService : IOrderService" クラスがあります。インターフェイスとクラスは同じアセンブリに配置されますか、それとも別のアセンブリに配置する必要がありますか?
ありがとう
編集
ご回答有難うございます。しかし、この場合、次の 4 つの質問について考えるようになりました...
1. UI に DataAccess アセンブリへの参照がある場合、開発者は UI コードで DataAccess クラスに直接アクセスできますが、コード レビューを行うための余分な労力が発生するべきではありません。 (たとえば、チームにジュニア開発者がいる場合)?
2. リポジトリ層 (実際のクエリを実行する) とサービス層 (OrderRepository クラスで GetOrdersByCustomerId メソッドを呼び出す) の両方に GetOrdersByCustomerId メソッドが必要であると理解しましたが、正しいですか?
3. また、(ほぼ) すべてのテーブルを維持するために CRUD 操作を行う必要があります。また、現在のプロジェクトに 96 個のテーブルがあると考えてください (多すぎませんが、少なくもありません)。Add、Update、Delete メソッドが必要です。サービス層でも?それとも、サービス層でもっと「行動」について考える必要がありますか?
4. OrderRepository に GetOrdersByCustomerById、GetOrdersByStatus などのメソッドがある場合、それは DAO クラスのようなものではないでしょうか。
c# - EF / Automapper と n 層アーキテクチャ
私のアプリケーションのアーキテクチャは次のように構成されています。
UI (クライアント側)
ユーザー インターフェイス (XAML)
VM (クライアント側)
すべてのビュー モデルのレイヤー。この層は、サービス層からの DTO と連携します。
サービス (サーバー側)
クライアントの通信インターフェース。クライアントは、このサービス層から DTO を消費します。このレイヤーは、DTO から EF エンティティ (およびその逆) への変換を行います。オートマッパーで変換を行います。
ドメイン (サーバー側)
ビジネスロジック全体がいくつかのドメインに分かれています。このレイヤーは、エンティティ フレームワークのエンティティと連携します。
データ アクセス (サーバー側):
データ アクセス層は EF と連携します。このレイヤーは、リポジトリ / 作業単位パターンで設計されています。
私の問題:新しいレコードの作成はうまくいきます。しかし、レコードを更新したい場合、EF は更新について知りません。常に新しいレコードを作成したいと考えています。問題は、EF が変更追跡メカニズム全体の参照を処理することだと思います。オートマッパーは常に新しいレコードを作成します。これは正しいです?
代替手段はありますか?
前もって感謝します。
よろしく、プロ
編集:私の問題の要約:
私の n 層アーキテクチャでは EF は更新されず、常に新しいレコードを作成しようとします。
それが役立つことを願っています。
asp.net - n層アーキテクチャ:複数のサービスにTransactionScopeまたはUnit of Workを使用していますか?
私は現在、次のレイヤーを持つnレイヤーアーキテクチャに取り組んでいます
- 表示(ASP.net Webアプリ)
- マネージャー(オーケストレーションサービス)
- サービス(ビジネスレイヤーは作業単位を使用します)
- リポジトリ(データアクセス)
今のところ、マネージャーは1つ以上のサービスを呼び出して、データへのアクセス、データの保存、またはその他のビジネスを行っています。サービスは、トランザクション内でサービスが使用されるように、実装された作業単位とリポジトリを使用しています。
これで、トランザクション内ですべて一緒に機能するさまざまなサービスを呼び出す必要があるマネージャーができました。
私の意見では、サービスはリポジトリを使用してデータベースにアクセスしているため、作業ユニットの呼び出しはサービスに保持する必要があります。作業単位の呼び出しをマネージャーに移動すると、設計が壊れます。Managerには、リポジトリへの参照が必要です。
アクセスを設計する方法についてアドバイスはありますか?
ありがとう!
c# - .net n 層 Web サイトの構造に関するアドバイスが必要
Entity Framework をデータ アクセス レイヤーとして使用して、最初の .net/c# Web サイトを作成しています。プロジェクトをレイヤーに分割して、DataAccess、BusinessLogic、別の BusinessObjects レイヤーを持ち、Web サイト自体が UI (Pages/UserControls/Appcode フォルダー) になるようにしました。追加のユーティリティ プラグイン プロジェクトもあります。
EF モデルは DA に移行し、エンティティの作成は BO に移行しました。すべてが良い感じですが、どのロジック クラスが AppCode (UI) に属し、何が BusinessLogic に属しているかに問題があります。
物事がどちら側に進むかを判断するのに役立つガイドラインはありますか?
.net - 依存性注入は横断的関心事ですか?
私はアプリを設計していて、n層アーキテクチャを使用しています。
次に、プロジェクトを特定のDIフレームワークから分離しようとしています。つまり、独自のIContainerインターフェイスを作成し、コンポーネントがこのインターフェイスのみに依存するようにします。
次に、2つの質問があります。
1-これは最後の良い習慣ですか?
2-(そしてより重要な)依存性注入は横断的関心事ですか?つまり、DI関連のコンポーネントを横断層に配置できますか?答えがどこにない場合は、それらのコンポーネントを適合させることができます。
私が横断的関心事についてアーキテクチャ設計ガイドに飛び込むとき、彼らは通常次のように言及しているので、私はこれを尋ねます:
asp.net - ビジネス層からの ASP.NET カスタム例外処理
私は OOP を初めて使用するので、これが正しい処理方法であるかどうかを理解するために助けが必要です。私は 3 層 Web プロジェクト (+ DTO) を持っており、ビジネス オブジェクトからプレゼンテーション層に「エラー」を返す最良の方法を理解しようとしています。特に今、私はこのユーザーの作成に直面しています。ウェブサイトの登録時にデータベースにユーザーを作成したいとしましょう。ユーザー名または電子メールが既に取得されているかどうかを実際のユーザーに伝える必要があります (これは単なる例です)。
たとえば、ASP.NET Membership.CreateUser() メソッドは、MembershipCreateStatus オブジェクト byRef を渡すため、このメソッドを使用して Enum (別の名前空間に存在します...) を返し、試行のステータスを渡します。これは、DuplicateEmail の可能性があります。 DuplicateUserName など。
例外に基づいて別の方法を実装しましたが、それについての意見をお願いします。ユーザーを作成する BLL マネージャー クラスで、ネストされた Excpetion クラスと、エラー タイプのネストされた Enum を次のように作成しました。
次に、UI レイヤー (aspx コード ビハインド) でマネージャーを呼び出し、次のように例外を確認します。
例外と列挙型の両方がこのマネージャーに非常に固有であるため、このルートをたどると、各マネージャーに関連する列挙型を持つネストされた ManagerException があることを考えると、これは正しいアプローチですか?
いつもご意見ありがとうございます。
Brian と Cyborg によって親切に提案された「カスタム コード」シナリオをフォローアップします (Brian の方がより完全であるという理由だけで彼の回答にマークを付けました。他のユーザーが MS のアドバイスに興味を持っている可能性があります)。良い考えでしょうか?これらの列挙型はこのマネージャー クラスに厳密に関連付けられるため (そして、BLL の各マナガー クラスには独自のクラスがあります)、ステータス コードが渡されたときにそれらを引き続き使用できると思いますか?
編集:私はこのようにリファクタリングしました...大丈夫だと思いますか?
そして、プレゼンテーション層では:
entity-framework - クラス生成用の EF5 データベースの最初のモデル テンプレート (tt)
既存のデータベースから作成されたすべてのエンティティが同じインターフェイスから継承されるようにしたいと考えています。
これはテンプレートを介して行うことができると思います。そして、私はその醜い.tt
ファイルを見てきましたが、助けはありません (または、私はそれを見つけていません)。
テンプレートのドキュメント、例などはありますか?
N 層設計やドメイン駆動設計など、一般的なパラダイムのヒントや既製のテンプレートはありますか?