0

コードを整理する方法について少し助けが必要です。これは哲学ではなく、本当の問題です。動作するソリューションを探しています。たとえば、phpやsymfonyフレームワークでは、コードを整理する方法が非常に明確でした。c＃.netでは、迷子になっていると感じます。
いくつかの部分を再利用して、プロジェクトを最初から書き直したいだけです。

説明
まず第一に、私は多くのプラットフォームを対象としているので、Windows Mobile、Windows Desktop、Android、Webは、データベースと直接通信するのではなく、Webサービスとして機能を公開する必要があるようです。これは正しいです ？
次に、いくつかのクライアントアプリケーションが必要です。wpf one、androidおよびwindowsmobile。

wpfでは、MVVMパターンを使用できると思います。

質問
私はADO.NETでpostgresqlを使用していますが、他の同様のアプリケーションと比較してパフォーマンスは驚くべきものです。Dapperが大いに役立つことがわかり、私が探していたものでした。しかし、SQLコードをどこに置くか問題があります。OK、私はモデルクラスを持っています..Customer、Oderなど...それではSQLコードをどこに置くべきですか？CRUDコードを別のクラスに配置する必要がありますか？現在、コントローラークラスにいくつかのコードがありますが、何かをしたいときは常に新しいコントローラークラスを作成しています。そして、これは本当に良くないようです。
データベースコードを整理するパターンはありますか？

4

3 に答える 3

1

ビジネスロジック層、データアクセス層、およびユーザーインターフェイスを使用するN層アプリケーションについて考えてみてください。詳細： http： //en.wikipedia.org/wiki/Multitier_architecture

これを実行し、DAL（データアクセス層）を介してすべてのストアドプロシージャまたはSQLコード（またはLINQ-To / EF）にアクセスします。

ただし、Webサービスを使用している場合（UIとBLレイヤーのみがあると思います）、これは必要ない場合があります。Webサービスを呼び出して、結果に対して必要な処理を実行するだけです。

したがって、アプリケーションはUIとBLのみになります。BLはWebサービスを呼び出し（DALがある場合と同じ方法で）、データを取得して必要な処理を実行します。

その場合、WebサービスはBLとDALになり、BLが要求/応答を処理し、DALと通信してデータをアプリケーションに返します。

于 2012-10-02T13:06:37.147 に答える
1

SQLコードはどこに置くべきですか、CRUDコードは別のクラスに置くべきですか？

はい、リポジトリパターンを見てください。データコードは個別であり、などのオブジェクトを返す必要がありますCustomer。Entity FrameworkまたはNHibernateは適切な機能を提供でき、業界標準です。

複数のフロントエンドから呼び出されるサービスレイヤーをその上に配置することもできます。

密結合を減らすために、レイヤー間でDIを使用するようにしてください。現時点ではStructureMapが好きですが、優れたフレームワークはたくさんあります。

ちなみに、MVCでもMVVMパターンを使用できます。

于 2012-10-02T13:13:20.000 に答える
1

バックエンド部分は、次の機能を提供する必要があります。

  1. クライアントとの連携：クライアントからの要求を処理し、応答をクライアントに送り返します。ここでの主な問題は、要求/応答形式を定義することです。SOAPまたはRESTを使用できます。たとえば、.NET Frameworkサービスフレームワーク（WCFなど）は両方のプロトコルで機能しますが、私にとっては、SOAP指向です。WCFは、サービスコントラクトを記述するために設定されたクラスを使用するため、純粋なADO.NETではなく一部のエンティティを操作する方がよいと思います。

  2. エラーについてクライアントに通知する：検証エラーと例外が含まれます。検証メッセージは、通常はプロパティ名でクライアントに表示する必要があり、例外も処理する必要があります。また、データベース関連のエラーの処理とドメインモデルエラーへの変換にも問題があります。

  3. に基づくWCFアーキテクチャservices-それはコントラクトであり、その実装は一連のプロトコルによってアクセスされます。WCFはエンティティのシリアル化と逆シリアル化を使用するため、ビジネスロジックをエンティティに配置することはお勧めできません。それを別々のクラス（repositories）に配置し、サービスからリポジトリを呼び出します。これはいわゆるanemic domain model-ドメインエンティティにはビジネスロジックが含まれていません-反対にrich domain model-エンティティにはビジネスロジックが含まれています。

  4. データベースへのアクセスは通常、データアクセス層（またはDAL）と呼ばれるクラスのセットにカプセル化されます。DALは、エンティティをデータベースに永続化するか、データベースからエンティティをロードするために必要な一連のメソッドを提供します。このメソッドにはビジネスロジックは含まれていませんが、データベースの詳細と構造をビジネスロジックレイヤーからカプセル化します。ORM（Entity Framework、BLToolkitなど）など、よく使用されるレイヤーヘルパーツールを実装するため。

  5. ビジネスロジック層（BLL）-DALのメソッドを使用してエンティティを永続化します。データベースと直接連携するべきではありません。DALからメソッドを呼び出すだけです。ビジネスロジックには、検証、計算、権限チェックなど、エンティティおよびエンティティセットを使用したすべての操作が含まれます。

編集

トランザクションをサポートするには、 TransactionScopeやORMに組み込まれているトランザクションサポートなどのデータベースクラスから切り離して使用できます。

ビジネスロジックをDAL操作に比較的依存しないようにすることは常に良いことです。つまり、エンティティについて知らない方法でビジネスレイヤープロセスエンティティが保存されます。可能であれば、データベーストランザクションをDAL内にカプセル化できますが、これには、多くのパラメーターを持つ醜いメソッドが必要であり、トランザクション内に保存するために多くのエンティティとコレクションを渡す必要があります。

ただし、通常は不可能であり、ビジネスロジック層のメソッドはDAL操作を数回呼び出します。追加のエンティティをロードして保存します。この場合、トランザクションスコープまたはORMアナログが適切な選択です。

于 2012-10-02T13:22:06.867 に答える