問題タブ [business-logic]

数ヶ月前にこれに出くわしたと思いますが、今は答えを見つけるのに苦労しています。おそらく誰かが私をドキュメントの正しいセクションに向けることができますか？

Sprint.NETを使用して、リモートXMLファイルを単一のアプリケーションコンテキストに結合し、エンジンオブジェクトをビジネスルールオブジェクトから分離します。問題は、いくつかのビジネスルールがオブジェクトではなく値であり、エンジンxmlのノードによって必要<property>とされることです。<constructor-arg>

別のオブジェクトのプロパティを参照する（ ？expressionの代わりに属性を使用するvalue）か、または特殊な名前/値リスト（たとえば<appsettings>、Springのバージョンtoなど）を参照することで機能します。

ドメイン ロジックとは ドメイン ロジックのウィキペディア ページは、ビジネス ロジックにリダイレクトされます。それらは同じものですか?そうでない場合、どのように違いますか?

私の同僚は、XSLT の用途の 1 つはビジネス ルールの処理であると述べました。彼は、ユーザーがある種のテキスト形式でビジネス ルールを記述できるシステムがあり、プログラムが XSLT を使用してテキストを処理し、アプリケーションで実行時にルールを適用できると述べました。

誰かが私のためにこの主題に光を当てることができますか?

ありがとう！

ほとんどのテンプレート エンジンは、デザイナーやフロント エンド開発者にとって使いにくく、プログラマーはそれらを維持する負担を負うことになると思います。

また、デザイナーが html モックアップを更新した後にテンプレートを頻繁に更新することは悪夢です。テンプレートが元の html と互換性がなくなるためです。

私は非常に長い間この問題を抱えていましたが、最近アイデアがありましたが、何かを再発明していないのか、それとももっと良いものが存在するのかわかりません。

それで、この問題のより良い解決策を見つけたかどうか、また見つけた場合はどれを見つけましたか?

ストアドプロシージャのビジネスロジックに対する賛否両論は何ですか？

私は (Spring MVC フレームワークを使用して) MVC Web アプリケーションを構築していますが、特定の領域を設計する最善の方法に少し困惑しています。

アプリケーションは一連の Web サービスとやり取りする必要がありますが、これらの Web サービスはそれほど大きく設計されておらず、それ自体であまり抽象化されていません。基本的に、作成/更新/取得/削除操作ごとに Web サービス メソッドがあります。それぞれの「データ型」であり、それ以上の API はあまりありません。Web サービス クライアントは、必要なデータを作成するために、どのメソッドをどの順序で呼び出すかを知る必要があります。つまり、「トランザクション」ベースのメソッドはありません。

たとえば、単純に新しいユーザー アカウントを作成するには、合計 7 つの異なる Web サービス メソッドを呼び出して、必要なテーブルのすべてのレコードをセットアップする必要があります (userレコード、そのユーザーへの正しいレコードの追加、privilegesユーザーの詳細のセットアップbillingなど)。 .

これを抽象化し、アプリケーション内にカプセル化する最善の方法に苦労しています。アプリのほとんどは、標準的なフローに従います。

アプリケーション内で、独自の「ドメイン オブジェクト」のセットを使用して、Web サービス WSDL で定義されたデータ型を表現および抽象化しているため、ドメイン ロジックは Web サービスの型に依存せず、抽象化および非表示にできます。私たちが好きな詳細。

私が意見を求めているのは、例として上で述べた「ユーザー作成プロセス」を設計するための最良の方法です。「通常のユーザー」を作成するプロセスには、前述のように 7 つの異なる Web サービスを呼び出すことが含まれますが、これはユーザーの「タイプ」の 1 つにすぎません。いくつかの異なるタイプのユーザーを作成できる必要があり、それぞれに異なる必要があります。呼び出される Web サービス。

現在、私はこの「通常のユーザー」の作成のみを、少しの概念実証としてUser設計UserDaoしました。 7 つの Web サービス メソッドについて言及しました。メソッドは によって呼び出されます。これは私のビジネス/サービスレベル クラスであり、 によって呼び出されます。getUser(name)createUser(User)WebServiceUserDaoUserDaocreateUser()UserCreationServiceSignupController

しかし、このロジックを拡張してさまざまなユーザー タイプを作成できるようにするには ( User.getType(). :

1. 「ユーザー タイプ」ごとに1 つのUserDao実装を作成して、各「ユーザー タイプ」を作成するロジックを独自のクラスにカプセル化して、UserCreationServiceどちらUserDaoを使用するかを決定できるようにします。これは、1 つのサービス クラス: 多くの DAO に対応します。
2. UserDaoアプリケーション全体がこれらの個々のタイプのそれぞれについて知る必要はありませんが、Web サービス/DB で作成する必要がある各「レコード」に対応する小さな部分に分割する必要がありますか? そしてUserCreationService、さまざまな異なる「ユーザータイプ」に対して異なる実装がありますか? つまり、対応するオブジェクトやドメイン オブジェクトが必要ない場合でも、この戦略には a PrivilegesDao、 aなどがあります。これは、多くのサービス クラス: 多くの DAO になります。BillingPlanDaoPrivilegeBillingPlan
3. 「ユーザー タイプ」ごとに Web サービスを呼び出す必要があるすべてのロジックを単一のWebServiceUserDao? これには、非常に複雑なクラスを持つという欠点があります (そして、PMD は循環的複雑性についてすでに不満を持っています) が、このロジックはすべて 1 つのクラスにカプセル化され、API 全体の観点から見ると複雑さが軽減される可能性があります。

このアプリケーションでの目標の 1 つは、データの永続性の詳細を変更する必要がある場合に、DAO の実装を変更するだけで済むようにすることです。別の課金システムとのインターフェイスを開始する必要がある場合は、アプリケーションのどの部分も、DAO レベル以外で変更したくありません。

ご意見はありますか？「ビジネス ロジック」と「データ アクセス ロジック」が重複しているように見える場合、どこを分割するかを決定する際に、どのような戦略を使用しますか?

次のタイプの検索機能を備えた Web アプリケーションを開発しています。

• 通常の検索: ユーザーが検索キーワードを入力してレコードを検索します。
• 人気:これは一種の検索ではなく、ウェブサイトで人気のあるレコードを表示します。これは、digg や他のソーシャル ブックマーク サイトと同じです。
• 最近:これで、Web サイトに最近追加されたレコードが表示されます。
• City Search:ここでは、"Delhi"、"Mumbai" などの都市名をユーザーに提示しています。ユーザーがこのリンクをクリックすると、その特定の都市のすべてのレコードが表示されます。
• タグ検索:都市検索と同じように、タグ リンクがあります。ユーザーがタグをクリックすると、そのタグでマークされたすべてのレコードがユーザーに表示されます。
• アルファベット検索:都市やタグと同じように、この機能にも「A」、「B」などの文字のリンクがあり、ユーザーが文字のリンクをクリックすると、その特定の文字で始まるすべてのレコードが表示されます。ユーザー

さて、私の問題は、上記の検索をユーザーに提供する必要があることですが、すべての検索レコードを表示する 1 つのページ (result.aspx) を使用するかどうかを決めることができません。ユーザーが使用している検索文字列と、ユーザーに表示する必要があるデータ。たとえば、都市、デリー、タグ デリー ホテルを検索すると、両方の URL は次のようになります。

都市の場合: www.example.com/result.aspx?search_type=city&city_name=delhi

タグの場合: www.example.com/result.aspx?search_type=tag&tag_name=delhi-hotels

通常の検索: www.example.com/result.aspx?search_type=normal&q=delhi+hotels+and+bar&filter=hotlsOnly

今では、すべての検索に 1 つのページを使用するという考えは面倒です。そこで、すべてのタイプの検索に別のページを使用する、よりクリーンなアイデアを考えました。

都市の場合: www.example.com/city.aspx?name=delhi

タグの場合: www.example.com/tag.aspx?name=delhi-hotels

通常の検索: www.example.com/result.aspx?q=delhi+hotels+and+bar&filter=hotlsOnly

最近の場合: www.example.com/recent.aspx

ポピュラーの場合: www.example.com/popular.aspx

私の新しいアイデアはよりクリーンで、どのページが何のためのものかを明確にユーザーに伝え、ユーザーが今どこにいるのか、どのレコードを見ているのかをユーザーに知らせます。しかし、新しいアイデアには 1 つの問題があります。検索結果の表示で何かを変更する必要がある場合は、すべてのページを 1 つずつ変更する必要があります。この問題の解決策も考えました。これは、リピーターの下でユーザー コントロールを使用することです。各レコードの HTML をレンダリングするために、すべての値を 1 つずつユーザー コントロールに渡します。

すべてが新しいアイデアでうまくいっています, しかし、私はまだ私が行かなければならないことを決めることができません. 誰かこの問題についてのあなたの考えを教えてください.

維持しやすく、SEO にやさしく (自分のウェブサイトのランキングを上げる)、ユーザーフレンドリー (ユーザーにとって使いやすく、理解しやすい) のアイデアを実装したい

ありがとう。

貧血ドメインモデルと関心の分離に関するいくつかの質問を読みました。貧血のドメインオブジェクトでドメインロジックを実行/アタッチするための最良のテクニックは何ですか？私の仕事では、かなり貧血のモデルがあり、現在、ドメインオブジェクトでデータベース/ビジネスロジックを実行するために「ヘルパー」クラスを使用しています。例えば：

アプリが購入を行う必要がある場合、StoreHelperを作成し、ドメインオブジェクトのメソッドを呼び出します。私にとって、Customer / Productが自分自身をリポジトリに保存する方法を知っていることは理にかなっていますが、ドメインオブジェクトにSave（）メソッドは必要ないでしょう。Customer.Purchase（Product）のようなメソッドでも意味がありますが、それはエンティティにドメインロジックを配置します。

これが私が出くわしたいくつかのテクニックですが、どれが良いか悪いかわかりません：

1. CustomerとProductは、基本的なCRUD操作を一般的な方法で提供する「Entity」クラスから継承します（ORMを使用する場合もあります）。
   • 長所：各データオブジェクトは自動的にCRUD操作を取得しますが、データベース/ORMに関連付けられます
   • 短所：これは、オブジェクトのビジネスオペレーションの問題を解決せず、すべてのドメインオブジェクトを適切でない可能性のあるベースエンティティに関連付けます。
2. ヘルパークラスを使用して、CRUD操作とビジネスロジックを処理します
   • 「純粋なデータベース」操作用にDAOを用意し、よりビジネス固有の操作用に個別のビジネスヘルパーを用意することは理にかなっていますか？
   • これには、非静的または静的ヘルパークラスを使用する方がよいでしょうか。
   • 長所：ドメインオブジェクトはデータベース/ビジネスロジックに関連付けられていません（完全に貧血）
   • 短所：あまりOOではなく、アプリケーションコードでヘルパーを使用するのはあまり自然ではありません（Cコードのように見えます）
3. エンティティが任意のリポジトリに保存するメソッドを持っている場合は、ダブルディスパッチ手法を使用します
   • 長所：関心の分離の改善
   • 短所：エンティティにはいくつかの追加のロジックがアタッチされています（ただし、分離されています）
4. C＃3.0では、拡張メソッドを使用して、ドメインオブジェクトに触れずにCRUD/ビジネスメソッドをドメインオブジェクトにアタッチできました。
   • これは有効なアプローチですか？長所/短所は何ですか？
5. 他のテクニック？

これを処理するための最良のテクニックは何ですか？私はDDDにかなり慣れていません（私はエバンスの本を読んでいます-それでおそらくそれは私の目を開くでしょう）

次のコードを検討してください。

つまり、OurPropertyinの値をOurBusinessObject変更したときに、値が有効でない場合は、デフォルト値に設定します。このパターンはコードの臭いとして私を襲いますが、ここにいる他の人（私の雇用主）は同意しません。あなたの考えは何ですか？

追加するために編集：なぜこれが大丈夫だと思われるのかについての説明を追加するように頼まれました。ビジネスオブジェクトのプロデューサーにデータを検証させるのではなく、ビジネスオブジェクトが自身のプロパティを検証し、検証が失敗した場合にクリーンなデフォルト値を設定できるという考え方でした。さらに、検証ルールが変更された場合、ビジネスオブジェクトがデータの検証とクリーニングを処理するため、ビジネスオブジェクトのプロデューサーはロジックを変更する必要がないと考えられていました。

12 mtd、12 mtd ローリング、および ytd 計算の違いは何ですか