2011-01-26 16 views
5

私はn層アーキテクチャを再評価しようとしており、経験に基づいていくつかの提案を得たいと考えています。ここに私たちの典型的な.NETのn層(時にはn層)の設計です。n層ビジネス/サービス層設計

Project.UI 
Project.Services 
Project.Business 
Project.Model 
Project.DataAccess 

DATAACCESSは、一般的にEntity Framework 4Repositoryクラスで構成されています。私はAggregate Rootのコンセプトに従ってテーブルのリポジトリを避けるために、私の経験では簡単に言っています。私は、リポジトリとテーブルの間に約70%の一致がある傾向があります。

モデルは通常、私のEntity Framework 4エンティティで構成されています。私は成功したセルフトラッキングEFエンティティを使用しています。

ビジネスは私が最も苦労しているものです。私は通常RepositoryごとにManagerクラスを持っています。このクラスには、.Add()のようなメソッドが含まれ、repository.Add()に転送する前にビジネス検証を行います。

サービスですが、実際には私がWebサービスベースのソリューションを作成しようとしている場合にのみ、これを実装します。この層は、DTOとエンティティとの間の要求/応答の整列を担当する。そして最も重要なことは、より多くのcoarse grainedインターフェイスを提供することです。例えば、本当にAccountManager.ValidateCashを(含まれる場合がありますビジネストランザクションのためfacadeあるTradingService.SubmitTrade()、)、OrderManager.SubmitOrder()など

懸念
は私のビジネス層は非常にエンティティです実際にはエンティティとリポジトリの間の接着剤であり、間に妥当性検査があります。私は、サービス層がリポジトリへの参照を保持している(本質的に "ビジネス層"をスキップする)多くのデザインを見てきました。本質的に、それは私のビジネス層と同じ目的を果たしますが、それは検証を行いますが、その責任(および命名)は、より高いレベルのより粗いビジネストランザクションです。上記の例を使用すると、TradingService.submitTrade()はビジネスマネージャクラスに委任されず、必要なリポジトリを照会し、すべての検証などを実行します。

私はビジネスを再利用できるという意味で私のデザインが好きです私は、すべてのリポジトリにマッチするビジネスレイヤマネージャがあり、余分な作業をたくさん作成するということは嫌です。おそらくソリューションは、ビジネスレイヤレベルで異なるタイプのグループ化ですか?たとえば、PhoneManagerやEmailManagerなどの個別のManagerクラス(電話機エンティティと電子メールエンティティを持っていることに注意してください)をContactsManagerなどのLogical Managerクラスに組み込みます(「Contact」エンティティタイプはありません)。 ContactManager.GetPhones()やContactManager.GetEmail()などのメソッドで

私はサービス層、ビジネス層、または両方を持っているかどうか、他の人たちがどのように組織し、責任を委任しているのか疑問に思います。 ORM文脈参照などを保持するもの

答えて

2

私はあなたの懸念の終わり近くに概説したことがある傾向があります。ビジネスレイヤーグループでは、ビジネス上の観点からより理にかなったマネージャーへのものがあります。

連絡先を使用すると、私は確かにPhoneManagerまたはEmailManagerを持っていないでしょう。 「ContactsManager」は、私にとってより有用なグループ分けであり、対処する管理者の数がより少なくても、ほとんど同じことが達成されます。ビジネスの観点から見ると、電話番号と電子メールは、連絡先のほんの一部です。彼らが独自のテーブルとエンティティを持っているからといって、彼ら自身のマネージャーが必要なわけではありません。それはあなたがそれらを再利用することができないという意味ではありません。複数の場所で電子メールアドレスを使用して作業する必要がある場合、ContactsManagerには関連する方法があります。

私たちの環境では、データベース/エンティティ層、次にビジネス・ルールとビジネス・ロジックを処理するサーバー上にあるビジネス層があります。そのビジネスレイヤーは、WCFを介したサービスとしてクライアントに公開されています(少なくとも、クライアントに関連するものは)。

あなたは何をしたいのか分かっているように聞こえるので、試して試してみることをお勧めします。 :)

+0

複数のビジネスマネージャークラスにまたがるサービスコールがありますか?言い換えれば、あなたのサービスインターフェイスは、ビジネスマネージャよりもさらに粗くなる可能性があります。たとえば、ContactManager.CreateUser()は、UserManager.CreateUser()とContactManager.AddEmail()、ContactManager.AddPhone()などに委譲します(ファサードとして機能します)。 PhoneRepositoryとEmailRepositoryを持つことに何も問題はありません。それは私には思われるリポジトリはマネージャのように "論理的"ではありません。 – e36M3

+0

まれですが、起こっています。できるだけ多くのロジックをビジネスレイヤーに保つことを好みます。なぜなら、誰かが私に後で来て、サービスと同じことをするWebページを望んでいるからです(そしてそうです)。 Webページはサービスを呼び出すのではなく、サービスと同じビジネスレイヤロジックを呼び出すことができます(私の場合は同じサーバー上にあります)。だから、私がこのような場合に行うことは、それ自体が他のビジネスマネージャを使用できるビジネスマネージャメソッドを持つことです。私はそれを避けようとしますが、シンプルさに本当の利益がある場合は除きます。 – Tridus

+0

私はあなたが何を意味しているのか知っています。私はDIを使ってマネージャーを作成し、コンストラクターを介して必要なリポジトリーを提供します。別のマネージャを作成するマネージャは、マネージャにDIコンテナを認識させる必要があります。しかし、これがなければ、時にはコピーして貼り付けることによって論理を複製しているようです。たとえば、DataEntryManager.EnterPrice()およびFileManager.UploadPriceFile()などです。あなたが言った "価格ファイル"を解析した後、我々は価格を挿入する必要があります想像することができます。私はそのロジックの一部を複製するか、FileManagerにDataEntryManagerを再利用させることができます。 – e36M3

関連する問題