2009-06-02 16 views
4

私は、アプリケーションの3つの層(表示 - > bal - > dal)で同じ列挙型を使用したいと思います。私はデータレイヤーで列挙型を定義しましたが、プレゼンテーションレイヤーで同じ列挙型を使用したい(プレゼンテーションレイヤーにはデータレイヤーへの参照がありません)。他の誰かのanswer私は似た質問と思われるものをを使用して、私は、ビジネス層で、次の列挙型を構築しました:階層間の列挙型

namespace bal 
{ 
    public enum TransactionCode 
    { 
     Accepted = dal.TransactionCode.Accepted, 
     AcceptedWithErrors = dal.TransactionCode.AcceptedWithErrors, 
     InvalidVendorCredentials = dal.TransactionCode.InvalidVendorCredentials, 
     BrokerOffline = dal.TransactionCode.BrokerOffline 
    } 
} 

これは階層間で列挙型を構築するための適切な方法は何ですか?

+0

ドメインの概念を使用していて、それは私の方がはるかに優れています。より審美的に楽しく、混乱も少なくなります。 – Rake36

答えて

5

1つのアプローチは、すべてのレイヤーで共有される1つの「レイヤー」(まったく実際のレイヤーではありません)を持つことです。

I blogged about this a while ago(現在休眠中のブログ/プロジェクトでは、残念ながら)。それは "不純な"ように見えるかもしれませんが、多くの点で人生をより簡単にし、重複を減らします。もちろん、柔軟性も低下します。プレゼンテーションの列挙型がのデータ層列挙体から異なるになるよう希望する場合は、リファクタリングする必要があります。

+1

ええと...彼が言ったのは^ –

+0

ありがとうジョン、これはほとんどの人のコンセンサスだね。あなたのブログの投稿はかなり有益でした。 – Rake36

0

これは本当にあなたのインタラクションがどのように進行しているかによって異なりますに。 dal.TransactionCodeからbal.TransactionCodeへの変換は、同等性を設定しようとしている操作ではほとんど機能しません。

本当にすべてのレイヤーに渡って、すべてのレイヤーを必要としている場合、私はそれをbalレイヤーで定義するか、UIからdalを参照します。

+0

私は平等面についても心配していました。 DALがBALやUIを参照してDALを参照することを希望しないので、私はJonによって提示されたDomainオブジェクトのアイデアを試してみましょう。 – Rake36

1

私の場合、私はこの種のもので別のプロジェクトを作成し、すべてのプロジェクトでそれを参照しています。

2

これらの場合、私は通常、自分の「データ型」を小さなアセンブリに分けます。次に、必要な場所でそのアセンブリを参照します。

2

実際にenumはAPIの一部です。階層化されたソフトウェアについて考えてみると、共有型について考えるのは難しいことがよくありますが、ほとんどの場合、一連のタイプは常にレイヤー全体で共有されます。だけではなく、標準のレイヤーについて考える:APIは、あなたのシステムの共有側面です

Presentation -> API 
|-> Business ----^ 
    |-> Data ----^ 

Presentation -> Business -> Data 

すると、このようにそれについて考えてみてください。 APIには、共有データ型、エンティティ、列挙型、サービスインターフェイスなどが含まれています。APIは独自のライブラリに分離してプレゼンテーションで再利用でき、ドメイン(ビジネスロジックとデータロジック)へのゲートウェイにもなります。

+0

jrista、私は実際にAPIを作成しています(小さなものですが)。私はあなたの答えが上記のJonとうまく収まると思います。 – Rake36

+0

APIを作成するときに便利なもう1つのこと。後でSOAに移行することが容易になります。 APIには、DTO、サポートタイプ(構造体、列挙型など)、サービスインタフェースが含まれます。 APIをいくつかのビジネスコンポーネントとサービス実装と組み合わせると、ドメインを持つことになります。APIをサービスクライアントライブラリ(たとえば、WCFクライアント)と組み合わせると、完全なクライアントサポートフレームワークが得られます。 APIを分離することで、組成と配布の可能性の全く新しい世界を開くことができます。 – jrista