問題タブ [service-layer]

フラットファイル経由でSSISを使用してメインフレームからデータをインポートする製品に取り組んでいます。SSIS パッケージは、ステージ データベースを使用してフラット ファイル データを変換し、ODS 内のストアド プロシージャを呼び出して、変換されたデータを読み込みます。すべての ETL データを (ストアド プロシージャを介して ODS に直接ではなく) .NET サービス レイヤーを介してルーティングし、ビジネス ルール/アクティビティなどを一元化する計画が考えられます。このアプローチに関する情報と反対意見を探しています。

現在、@ManyToOne親エンティティに関連付けられている子エンティティがあります。以前の開発者はlazy="false"、セッションが閉じられたときに必要なときにいつでも親を取得するようにこのフィールドを設定しましたlazy="true"が、常に使用されるとは限らないため、そうする必要があると判断しましたが、そうするとLazyInitializationException、セッションが閉じられ、子が親を取得しようとしたときのセッション。

run以下に示すように、メソッドのロジックをsと相互作用するサービスクラスに移動するのが正しいかどうか疑問に思っていました。したがって、現在、サービスクラスは、必要なsが挿入されDAOたプレーンクラスのようなものであり、単に呼び出すだけなので、例外を回避できます。メソッドと結果を返しますDAO。DAOエンティティと対話するサービスクラスにもっと多くのメソッドを配置する必要があります。これにより、ユーザーが取得され、ログインアクションのすべてがチェックされ、必要に応じて親が取得され、ログイン結果がrunメソッドに返されます。

私はSpringを使用<tx:advice>して、クロージングやその他のトランザクション関連のものを処理します。

私は最近、MVC アプリでフォーム データを最適に処理する方法についてのディスカッションで、Jani Hartikainenによってサービス レイヤーについて紹介されました。いくつか読んだ後、私はこのアプローチの利点を本当に見ることができます. 私の質問はこれです：

サービス クラスはどのように構成する必要がありますか?

• まず、モデルuser_service()に適切なクラス名user()はありますか、それとも別の標準がありますか?
• 私のサービスのメソッドは 1 つのタスクしか実行しないため、これらは常にstatic function. サービス クラスはデータを表すのではなく、一連のアクションであるため、これは適切なようです。
• サービス メソッドは 1 つだけを受け入れる必要argumentがありarrayます。

ユーザーデータを保存するために、フォームがコントローラーにデータを投稿したとします。

次の理由から、これは良いアプローチだと思います。

• controllerフォームに別のフィールドを追加できます。更新する必要はありませんservice。コントローラーは、渡されたデータが何であるかを気にする必要はなく、単に渡されたということは正しいようです。これにより、コントローラーが小さくなり、モデルのロジックが小さくなります。
• を渡さなかった場合array、複数の引数を持つ関数をセットアップできました。たとえば、私の機能はupdate_preferences($firstname, $lastname, $email). ただし、これは 20 を超える引数を持つ関数 (大きなフォームの場合) を作成する可能性があり、その順序は操作するのがひどくなります。
• を渡すこともできますがobject、それは意味がありますか? オブジェクトを作成している場合、それはそれが表すオブジェクト (この場合はユーザー) である必要がありますよね? しかし、コントローラーがユーザー オブジェクトをインスタンス化することに意味があるでしょうか。そもそもそれがサービス層の要点ではないでしょうか?
• おそらく、複数の引数を持ついくつかのメソッド (1 つから 3 つしかない場合) と、配列を受け入れるいくつかのメソッド (多数のフィールドがある場合) を持つための議論があるかもしれません。特定のメソッドが何を求めているかを知るには、常にクラスを参照する必要があるため、これは悪夢のように思えます。

ここで行うべき正しいことについて誰か意見がありますか? 私は正しい軌道に乗っていますか？過去に何をしましたか？どうもありがとう！

要求されたレコードが存在しない場合、または呼び出し元が許可されていないためにアクセスできない場合に、多くの場所でnullを返すレガシーサービスレイヤーを使用するプロジェクトで作業しています。IDからリクエストされた特定のレコードについて話しています。たとえば、次のようなものです。

最近、このAPIを変更するか、代わりに例外をスローする新しいAPIを追加するようにプッシュしました。チェックされた例外とチェックされていない例外についての議論が続いています。

JPA / Hibernateなどの設計者からのメモをとって、チェックされていない例外が最も適切である可能性があることを提案しました。私の主張は、APIのユーザーがこれらの例外から回復することを合理的に期待することはできず、99％の場合、エラーが発生したことをアプリケーションユーザーに通知することができます。

ランタイム例外を一般的な処理メカニズムまで伝播させることで、エッジケースの例外の処理に伴う複雑さと必要なブランチ処理の多くが明らかに軽減されます。しかし、そのようなアプローチを取り巻く多くの懸念があります（当然そうです）。

JPA / EJBやHibernateなどのプロジェクトの設計者が、チェックされていない例外モデルを選択したのはなぜですか？それには非常に正当な理由がありますか？長所/短所は何ですか。これらのフレームワークを使用している開発者は、アダプターラッパーなどを使用して、スローされた場所の近くでランタイム例外を処理する必要がありますか？

これらの質問への回答が、私たち自身のサービスレイヤーに関する「正しい」決定を下すのに役立つことを願っています。

速いもの。サービスとサービス層の違いは何ですか? インターネットで良い答えを見つけることができませんでした

何年もの間、私は同じコードを（進化を伴って）何度も何度も再実装してきましたが、それを抽象化するためのクリーンで効率的な方法を見つけることはありませんでした。

このパターンは、サービスレイヤーの基本的な「find [Type] s」メソッドであり、選択クエリの作成をサービス内の1つのポイントに抽象化しますが、より使いやすいプロキシメソッドをすばやく作成する機能をサポートします（PostServivce :: getPostByIdの例を参照）。 （）以下の方法）。

残念ながら、これまでのところ、私はこれらの目標を達成することができませんでした：

1. 個別の再実装によって発生するエラーの可能性を減らします
2. オートコンプリートのために、有効/無効なパラメーターオプションをIDEに公開します
3. DRYの原則に従う

私の最新の実装は通常、次の例のようになります。このメソッドは、条件の配列とオプションの配列を取り、これらからDoctrine_Queryを作成して実行します（今日、これをほとんど書き直したので、タイプミスや構文エラーが発生する可能性があります。直接のカットアンドペーストではありません）。

ピューフ

この基本機能の利点は次のとおりです。

1. スキーマの進化に合わせて、新しい条件とオプションをすばやくサポートできます
2. これにより、クエリにグローバル条件をすばやく実装できます（たとえば、デフォルトのtrueで'excludeDisabled'オプションを追加し、呼び出し元が明示的に別の言い方をしない限り、すべてのdisabled = 0モデルをフィルタリングします）。
3. これにより、プロキシがfindPostsメソッドにコールバックする新しい、より使いやすいメソッドをすばやく作成できます。例えば：

このアプローチの主な欠点は次のとおりです。

• 同じモノリシックな'find[Model] s'メソッドがすべてのモデルアクセスサービスで作成され、ほとんどの場合、条件スイッチ構造とベーステーブル名のみが変更されます。
• AND/OR条件操作を実行する簡単な方法はありません。すべての条件は明示的にANDされます。
• タイプミスの多くの機会をもたらします
• 規則ベースのAPIの中断に多くの機会をもたらします（たとえば、後のサービスでは、orderByオプションを指定するために別の構文規則を実装する必要があり、以前のすべてのサービスにバックポートするのが面倒になります）。
• DRYの原則に違反します。
• 有効な条件とオプションはIDEオートコンプリートパーサーに隠されており、オプションと条件のパラメーターでは、許可されたオプションを追跡するために長いドキュメントブロックの説明が必要です。

過去数日間、私はこの問題に対してよりOOのソリューションを開発しようとしましたが、あまりにも複雑で、使用するには制限が厳しすぎるソリューションを開発しているように感じました。

私が取り組んでいたアイデアは、次のようなものでした（現在のプロジェクトはDoctrine2 fyiになるので、少し変更します）...

そして最後に、Foo \ Service \ PostService \FindConditionsクラスのサンプル：

Foo \ Options\FindConditionsとFoo\Options \ FindOptionsは非常によく似ているため、少なくとも今のところ、どちらも共通のFoo\Options親クラスを拡張しています。この親クラスは、許可された変数とデフォルト値の初期化、設定されたオプションへのアクセス、定義されたオプションのみへのアクセスの制限、およびDqlOptionsMapperがオプションをループするためのイテレーターインターフェイスの提供を処理します。

残念ながら、これを数日間ハッキングした後、私はこのシステムの複雑さに不満を感じています。現状では、条件グループとOR条件はまだサポートされておらず、代替条件比較演算子を指定する機能は、FindConditionsを指定するときに値をラップアラウンドするFoo \ Options \ FindConditions\Comparisonクラスを作成することの完全な泥沼でした。値（$conditions->setCondition('Foo', new Comparison('NOT LIKE', 'bar'));）。

誰か他の人の解決策が存在する場合はそれを使用したいのですが、私が探していることを実行するものはまだありません。

このプロセスを超えて、実際に取り組んでいるプロジェクトの構築に戻りたいのですが、終わりが見えません。

だから、スタックオーバーフラワー：-欠点を含めずに私が特定した利点を提供するより良い方法はありますか？

ArticleRepository (Doctrine 2) とコントローラー (Zend Framework) の間のレイヤーであるサービスが認証/承認を処理する必要があるのか​​、それとも別のサービス/レイヤーの一部であるべきなのか疑問に思っています。

Web サイトの Zf コントローラーとリモート クライアントの API の両方でサービスを使用する必要があるため、疑問に思っています。

フィードバック?

私が現在取り組んでいるプロジェクトには、サービス、ウェブなど、すべてで使用されるコア API があります。

この API には次のレイヤーがあります。

• 芯
• Core.Models
• Core.DataProvider
• Core.DataProviders.LinqToSql
• Core.Utils

この API の上には、私の ASP.NET MVC アプリケーションがあります。これは次のようになります。

• ウェブ
• Web.Models (いくつかの Web 固有のオブジェクトとロジック。たとえば、スケジューリング テーブルで 1 日をレンダリングするのに役立つ四半期のリストを作成するクラス。)
• Web.Extensions (Html ヘルパー、コントローラー ベースなど)
• Web.ViewModels (ビューに渡す複合オブジェクト。)
• Web.Services (Core および Web.Models と通信するレイヤー。このレイヤーはコントローラーの ViewModel を構築します。コントローラーをクリーンに保つのに役立ちます。)

この設定に重大な欠陥はありますか?

より具体的な質問: コアに渡す前に、View からのいくつかのものを解析する必要があります。これをコントローラーまたはサービスレイヤーで処理する必要がありますか?

私は一般的な開発戦略を学んでいますが、それらについて多くの疑問が頭の中にあります。そのうちの 1 つは、依存関係を持たないアプリケーション レイヤーの作成に関するものです。プレゼンテーション レイヤー。たとえば、MVC アプリケーションでは、アプリケーション サービスがあるとしますが、このアプリケーション サービスは、プレゼンテーション層からの受信データ モデルの検証をチェックしません。これは、ASP.NET MVC 検証を介してコントローラーでのみチェックされます。サービス層には、内部に承認要素が含まれていません。すべての作業はプレゼンテーション層で行われます。それは正しいアーキテクチャだと思いますか？サービス層内にすべての検証と承認を再度含める必要がありますか? はいと言ったらどうやって？

サービス層に承認を含めるにはどうすればよいですか? サービスレイヤー内で認証を制御する方法が本当にわかりません。サービスレイヤーでも検証を複製しても問題ありませんか?

結局のところ、プレゼンテーション層が変わらないと確信している場合、そのようなデザインを作成する価値はありますか?

私は、保守とテストが容易なアーキテクチャを構築するための最良の方法を見つけようとしています。いくつかのプロジェクトを経て、私はいくつかのかなり悪いアーキテクチャを見てきました、そして私は自分のプロジェクトで将来の間違いを犯さないようにしたいと思います。

かなり複雑な3層アプリケーションを構築していて、DDDを使用したいとします。私の質問は、ビジネスロジックをどこに配置すればよいかということです。一部の人々は、それをサービス（サービス層）に配置する必要があると言いますが、それは理にかなっています。単一責任の原則に準拠した多数のサービスを持つことは理にかなっています。

ただし、これはアンチパターンであり、ビジネスロジックをサービス層に実装するべきではないと言う人もいます。どうしてこれなの？

署名付きIAuthenticationServiceのメソッドがあるとしましょう。bool UsernameAvailable(string username)このメソッドは、ユーザー名が使用可能かどうかを確認するために必要なすべてのロジックを実装します。

「これはアンチパターンです」という群衆によると、ここでの問題は何ですか？