1

私は新しいプロジェクトの開始段階にいます。私は常に自分自身を改善し、過去からの過ちを回避しようとしているので (誰もがいくつかの荷物を持っています) 、.NET のレイヤード アーキテクチャ サンプルを見ました。データとビジネス ロジックを見ると、データ レイヤーが実際に ExpenseSample.Business.Entities アセンブリへの参照を持っていることがわかりました。そのため、データ レイヤーはビジネス レイヤーがあることを認識しています。それはちょっとぎこちなく見えます。

確かに、DataObject を BusinessEntities にマッピングすることで時間を節約できますが、「危険な」アプローチではありませんか?

いくつかの議論とおそらくより良い解決策を楽しみにしています.

更新: ご意見ありがとうございます。今使ってる

MyApp.Data.Contracts.*
MyApp.Data.Access.*         /* has the classes to access the DB and maps it to 
                               the Data.Contracts */
MyApp.Business.Entities.*
MyApp.Business.Components.* /* accesses the classes from Data.Access, 
                               maps the Contracts to the Business.Entities and 
                               provides the components to access them */

このようにして、データの表現に対する内部的な変更が外側のレイヤーに影響を与えないようにすることができます。

4

4 に答える 4

2

私は同意しません、いくつかのオブジェクトはすべてのレイヤーからアクセスする必要があります、私はこれを次のようにします：

-----------
| DAL | E  |
------- N  |
| BAL | T  |
------- I  |
|  G  | T  |
|  U  | I  |
|  I  | E  |
|     | S  |
-----------

DALは通常WCFサービスに接続されており、残りのアプリケーションがそれを認識できるように保護します（したがって、WCFが古くなった場合は数年以内に変更できます）。

BALは主にアプリケーションに固有です（ただし、別のアプリで再利用できます）が、エンティティはアプリケーション専用に作成されているため、他の場所で使用する可能性はほとんどありません。

もちろん、これはかなり小さなアプリの場合であり、他のdll（モジュール、サードパーティなど）で拡張して、はるかに複雑にすることができますが、それがアイデアです。

私が言おうとしているのは、エンティティとBALは2つの異なるものであり、混同しないでください;）

于 2011-11-11T14:58:47.917 に答える
1

原則として、下位層は上位層に関する知識を持ってはいけません。ビジネス エンティティは DAL ではなく BAL の一部であるため、この例は正しくありません。したがって、データ層ではなく、ビジネス層がマッピングを行う必要があります。

マッピングにはそれほど時間はかかりません。ValueInjecterなどを使用するだけです。

免責事項: リンクされたサンプルは見ていません。一般的なレイヤリングについて2セントを与えるだけです。

于 2011-11-11T14:20:53.160 に答える
0

...データ層はビジネス層があることを認識しています

という名前の名前空間があることを認識しているだけですBusiness.Entitiesが、これらのエンティティは確かにアーキテクチャ内のリーフです。それらは、.Net フレームワーク以外には何も依存していません。エンティティには実際には (ToString() を除いて) ロジックが含まれていないため、アーキテクチャ全体でデータ コントラクトとして機能しているだけです。また、他のプロジェクトへの参照もありません。それらをPOCOにしない唯一のことは、それらがシリアライゼーションを認識していることです。

Baboon が述べたように、このアプローチは可能であり、これが非常にうまく機能する例があると確信しています。そして、プロジェクトとコードを見ると、すべてがとても素敵で居心地が良いように見えます。

そして、アーキテクチャ全体へのすべての追加を慎重に計画し、すべての変更を確認し、開発者と緊密なコミュニケーションを取っている限り、それは素晴らしく整然としたものになります。しかし、アーキテクチャ、データベース、およびビジネス プロセスがより急速に進化するとすぐに、共通のオブジェクトを使用してこれらすべてのレイヤーのデータをモデル化するために、さらに拡張する必要があります。私の意見では、レイヤー固有のデータ コントラクトを支持する例がいくつかあります。その中には、いつの日か UI プログラマーが、UI レイヤーのオブジェクトに PropertyChanged 通知機能を持たせたいと考えているということがあります。うーん！BAL と DAL にも影響を与えずにそれを行うことはできません。別の日、エンティティに GUI のみのプロパティ (表示色、画面上の位置、選択状態など) を保存したい場合に出くわしました。何' データベースはそれと関係がありますか？注意深く見ると、エンティティには既にレイヤー固有の処理が適用されていることがわかります。ナビゲーション プロパティの仮想キーワードを見ましたか? それらは、EF がそれらをサブクラス化し、遅延読み込みが有効なプロキシ クラスを提供できるようにするために存在します。これは、サービスを介して送信されることを意図していない可能性があります。

別の方法は、オブジェクト マッピングを使用することです (手動、テンプレート、または AutoMapper などのライブラリによる)。このソリューションは、コードの重複や何行ものマッピング コードがあるため、確かにクリーンではなく、居心地が悪いです。しかし、これにより、レイヤー内のデータを分離し、各レイヤーの特定のニーズに従ってモデル化することができます。

于 2011-11-11T18:27:35.867 に答える
0

私が言いたいことの 1 つは、DAL がビジネス オブジェクトにアクセスできるようにする場合は、1 つのプロジェクトを作成し、BAL と DAL をそのプロジェクト内の別のディレクトリと名前空間に分けることです。少なくとも、レイヤリングについて冗談を言っているわけではありません。

私が取り組んできたほとんどのプロジェクトでは、BAL と DAL を別々のアセンブリに分離してもほとんどメリットがありませんでした。データベース ソリューションが変更される可能性が高く、自分自身を将来的に保証したい場合は、代わりに nHibernate のような ORM を使用してください。

于 2011-11-11T14:16:51.883 に答える