問題タブ [service-layer]

サービス層に汎用抽象クラスを実装しようとしています。私はすでにdaoレイヤーで同様のパターンを使用しており、正常に機能します。Spring inPracticev8の電子ブックで実用的な例を見つけました。次の動作するコードを自動配線する方法があるかどうか疑問に思っています。（コードは機能しますが、クラス内の他のメソッドを使用する前に、ヘルパーメソッド'setDao'を呼び出す必要があります）

テストクラス：

MyServiceImplクラス

MyServiceインターフェース

AbstractServiceImplクラス

AbstractServiceインターフェース

サービス層で DbContext を公開するのは悪い習慣ですか?

例えば：

ここで、IDatabaseFactory は DbContext オブジェクトを返すことができます。ここで公開したのは、SkillLevels 以外のエンティティが必要な場合に、このサービス クラスで使用できるようにするためです。ご存じのとおり、データを取得するために複数のテーブルを選択する必要がある複雑なクエリの場合。

しかし、それが悪い習慣になるかどうかはわかりません!!

どんな助けでも大歓迎です。ありがとう。

次の2つのシナリオを検討してください。

• ユーザーがビューのボタンを押し（例：注文の履行）、ビューをすぐに更新したい（ボタンを無効にする、プログレスバーを追加するなど）
• サービスレイヤーはビジネスイベントを発生させますが、これは最終的にビューに反映される必要があります（たとえば、製品が在庫切れになっている場合）。

どちらの場合も、ビューモデルを更新するために何らかのメカニズムXが合法的に必要です。MVVMを使用すると、ビューは、イベントハンドラーでビューモデルのプロパティを設定するか、コマンドバインディングを介して、またはその他のメカニズムを介してこれを行うことができます。

サービス層は、何らかのメカニズムYを使用してこれを行うことができます。たとえば、ビジネス/ドメインモデルでイベントを発生させたり、ビューモデルを操作するコマンドを作成したり、ビューモデルでメソッドを呼び出したりします。

実際、XとYは同じメカニズム（またはパターン）である可能性があります。

これを行うのに良いものは何ですか、それはMVVMの精神を維持しますが、DRYですか？

現在、私は次の構造を持っています：

Doctrineを使用しているので、各フォルダーが1つのエンティティに対応するため、この構造を選択しました。このように整理することに問題はありますか？

組織の悪さによる今後のフォルダ構造の変更を回避する方法について、ご意見をお聞かせください。サービスレイヤーからクラスを整理するためのより良い方法はありますか？あなたは何をお勧めできますか？ありがとう。

Rails 3で内部サービスレイヤーを作成する場合、コードをどこに配置する必要がありますか？私はGrailsのバックグラウンドから来ており、Railsで同等のサービスが何であるか疑問に思っています。

また、これが記事やオンラインビデオでカバーされている場合は、リンクが必要です。ありがとう。

モデル、リポジトリ、サービス、コントローラー、場合によってはビューモデル、およびビューのレイヤーに分離された ASP.Net MVC 3 Web アプリケーション (EF 4.1) に取り組んでいます。

今私の質問はベストプラクティスの1つです。別のエンティティにアクセスする必要があるエンティティ サービス クラスは、そのサービスまたはそのリポジトリを使用する必要があります。たとえば、エンティティ A のサービス メソッドが、エンティティ A の作成時にエンティティ B を更新する必要があるとします。A のサービス クラスは B のリポジトリまたはサービス レイヤーを使用する必要がありますか? どちらも可能ですが、ベストプラクティスは何ですか? 個人的には、サービスが別のサービスにアクセスすることを好みます。そうすれば、いわばより進化したメソッドへのアクセスとなります。

サービス層についてアドバイスが必要です。私がこのモデルを持っているとしましょう：

Notes と Comments のリポジトリがあるとします。以下は、サービス レイヤーの例です (TDto は、エンティティをフラット化する DTO を表します)。

これは問題なく機能しますが、アプリケーション レイヤーでコードを複製することになると思います。したがって、Asp.Net MVC を使用していた場合は、コメント コントローラーとノート コントローラーを使用できます。各コントローラーで添付ファイルを作成するためのメソッドを作成する必要があります。

Document サービスを分離して、Document コントローラーを使用できるようにする方法を考えています。唯一の注意点は、エンティティをアプリ レイヤーに公開したくないということです。TDto を使用してドキュメント サービス メソッドを入力し、ある種のファクトリを使用してリポジトリとエンティティ タイプを取り込むという考えがありました。つまり、DTO タイプに基づいて、関連エンティティを検索すると、おそらく switch ステートメントであり、エンティティ タイプとそのリポジトリを起動します。

追加情報: EF 4.1 での私のマッピングは、Note_Attachments と Comment_Attachments のテーブルがあるようなものです。

サービスレイヤーでリポジトリパターンを使った「ストアフロントスターターキット」を見ていました。ビデオでは、彼はサービスレイヤーを使用している理由を実際には説明していませんでした。それらはただ余分なようです。

サービスレイヤーを使用することの長所と短所は何ですか？

一般的に、サービスレイヤーはUIインターフェイスから完全に分離されています。

ただし、UIとサービスレイヤーの間に何らかの依存関係がある可能性はありますか？例を挙げてください。

iPadに最適化されたUIを設計し、既存のデスクトップUIがあるので、この質問をします...理想的には、プレゼンテーションレベルまたはJSP、iPadUIのCSSの変更のみが必要です。 iPadの場合は1-1になります。つまり、既存のデスクトップバージョンとは（UIデザインだけでなく）わずかな違いがある可能性があります。

だから私はこの文脈でこの質問をしています。

エンティティごとのリポジトリから集約ルートごとのリポジトリにアプリケーションをリファクタリングしようとしています。

基本的な例として、Cars のエンティティ ルートがあるとします。車にはレンタカー契約があります。私が見る限り、契約は車なしでは存在しないため、車は集約ルートです。

システム内のすべてのコントラクト (ルート エンティティのすべての子エンティティ) を表示するユーザー ビューを実装しようとしています。リファクタリングする前に、コントラクト リポジトリに移動して All を取得するだけで済みました。コントラクト リポジトリが削除されたため (ルートではないため)、すべての車をリポジトリから取り出して、すべてのコントラクトを取得する必要があります。

私のリポジトリにはインターフェースがあります

ICarManagementService を作成し、GetAllContracts メソッド (おそらくフィルター パラメーターを使用) を持たせることを考えました。それは、契約ですべての自動車エンティティを引き出してから、雇用契約に関連付けられている各エンティティを取得してそれらをフィルタリングするために必要なすべての契約を取得することを意味しますか?

次に、これらをコントローラーに渡し、以前と同じようにコントラクトを AutoMap します。

これはベストプラクティスですか？

ありがとう

グレアム