2009-05-04 11 views
0

ご協力いただき、ありがとうございます。c#(wcf)アーキテクチャのファイルとディレクトリ構造(およびインスタンス化)

私は適切にモジュール化しようとしているwcfサービスを持っています。

もっと良い方法があるのか​​、ファイルとディレクトリ構造をinstanciatationで実装するのか興味があります。欠けているかもしれないより適切な抽象的な方法がありますか?

これが最善のアプローチですか?特に性能と何千という同時リクエストを処理する能力がある場合は?

現在、私はこの次の構造を持っている:

-Root \ Service.cs

 
public class Service : IService 
{ 
    public void CreateCustomer(Customer customer) 
    { 
     CustomerService customerService = new CustomerService(); 
     customerService.Create(customer); 
    }

public void UpdateCustomer(Customer customer) 
{ 
    CustomerService customerService = new CustomerService(); 
    customerService.Update(customer); 
} 

}

-Root \顧客\のCustomerService.cs

 
pulbic class CustomerService 
{ 
    public void Create(Customer customer) 
    { 
     //DO SOMETHING 
    }

public void Update(Customer customer) 
{ 
    //DO SOMETHING 
} 

public void Delete(int customerId) 
{ 
    //DO SOMETHING 
} 

public Customer Retrieve(int customerId) 
{ 
    //DO SOMETHING 
} 

}

注意を:この例ではCustomer ObjectまたはDataAccessライブラリは含まれていません。そのサービスについて忘れてしまった。

もし私があなたの考えを知っていれば、もっと良い方法を知っているか、助けてくれるリソースを教えてください。

ありがとうございました。 Steven

答えて

0

ウェブサービスソフトウェア工場を使用し、その構造が好きです。これは、いくつかの理由でunanswerかもしれないが、私は質問の広さは、それを行うにはたくさんあるだろうと思うだろう

BYA.Mfg.SCM.Svc.WCF 
    Source 
    Business Logic 
     BYA.Mfg.SCM.Svc.WCF.BusinessEntities 
     BYA.Mfg.SCM.Svc.WCF.BusinessLogic 
    Resource Access 
     BYA.Mfg.SCM.Svc.WCF.DataAccess 
    Service Interface 
     BYA.Mfg.SCM.Svc.WCF.DataContracts 
     BYA.Mfg.SCM.Svc.WCF.FaultContracts 
     BYA.Mfg.SCM.Svc.WCF.MessageContracts 
     BYA.Mfg.SCM.Svc.WCF.ServiceContracts 
     BYA.Mfg.SCM.Svc.WCF.ServiceImplementation 
    Tests 
0

:自分のサンプルコードで

構造はこのようなものでした。また、少しの文脈でデザインを分析するのはちょっと難しいです。ここには多くの質問があり、答えが複雑になります。

まず、サンプルコードに含まれていないいくつかのクラスについて説明しました。 CustomerがCustomerServiceを参照し、他のクラスや例についても同様に扱います。

あなたが体調をとる良い方法があるかどうか尋ねました。 "FlyWeight"パターンや "Factory"パターンのようなデザインパターンを参照して、これを手助けすることができます。あなたがパフォーマンスについて話したので、私は "FlyWeight"と言います。

デザインパターンの本がお手伝いします。また、Martin Fowlerによるリファクタリング(Javaで書かれていますが)も大いに役立ちます。

+0

fooMonster。 助けてくれてありがとう、私はこの例で多くの情報を提供していました。 私は質問を編集しました。あなたがそれを見て別のチャンスを得たら、私はそれを感謝します。 ありがとう、Steven – stevenrosscampbell

0

私はこれがという最高の(または推奨される)ディレクトリ構造であるかどうかわかりませんが、これは私が今決めているものです。このディレクトリ構造に基づいて

.\MyProject 
|----\bin 
|----\MyProject         (main application) 
|----\MyProject.Core       (shared libraries) 
|----\MyProject.Server       (WCF-hosting Windows service) 
|----\MyProject.Services      (the WCF services) 
|---------\MyProject.Services.Service1   (WCF Service1) 
|---------\MyProject.Services.Service1.Support (WCF Service1-specific libraries) 
|---------\MyProject.Services.Service2   (WCF Service2) 
|---------\MyProject.Services.Service2.Support (WCF Service2-specific libraries) 

とあなたがこれまでに示してきた、サービスクラスがMyProject.Servicesディレクトリの下MyProject.Services.Serviceフォルダに行くだろう。 CustomerServiceクラスは、MyProject.Servicesディレクトリの下のMyProject.Services.Service.Supportフォルダに格納されます。

複数の同時接続を開くか、同じ接続を何度も何度も繰り返し再利用することのトレードオフを理解するのに十分なデータベースで作業していません。私の推測では、それをやっているやり方が望ましい解決策だということです。

WCFサービスが呼び出されるたびに(新しいCustomerServiceオブジェクトを作成することによって)データベースへの処理を延期することを前提とすると、WCFサービスをシングルトンにすることでメリットが得られます。一般的に、WCFシングルトンは、スケーラビリティの理由から、さまざまなサービスコールの間で状態を共有し、同期する必要があるため、戸惑うことがあります。ただし、示されているように、WCFサービスは状態を直接維持しません。単にデータベースにアクセスして、顧客を作成、更新、削除、またはフェッチするだけです。適切なロッキングスキームを使用してデータベースにアクセスする限り、WCFサービスのコールごとのインスタンス化に関連するオーバーヘッドを回避できます。サービスをシングルトンにするには、サービスで次の属性を使用します。

[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)] 
public class Service : IService 
{ 
} 
関連する問題