問題タブ [model]

2 つのフォーム値の一意性を検証する Rails モデルがあります。これら 2 つの値が一意でない場合、検証エラーが表示され、[送信] ボタンが [再送信] に変更されます。ユーザーが「再送信」ボタンをクリックして、モデルの検証をバイパスできるようにしたいと考えています。Railsの検証ドキュメントから次のようなことをしたい：

validates_uniqueness_of :value, :unless => Proc.new { |user| user.signup_step <= 2 }

しかし、チェックできるモデルに値がありません...「再送信」値を持つパラメータだけです。

これを行う方法についてのアイデアはありますか？

モデルに Person クラスがあり、その属性のうち 15 個をビューのラベルに割り当てたいと考えています。ビューはモデルにアクセスすべきではありません。これは、コントローラーが Person の作成を処理することを意味します。ビューはコントローラーからこれらの Person 属性をどのように取得しますか? Controller に Person 型のメンバーが含まれている場合、View は次のような処理を実行できます。

lblFirstName.Text = theController.Person.FirstName;

lblLastName.Text = theController.Person.LastName;

lblCity.Text = theController.Person.City;

ただし、ビューはまだモデル (つまり、人物) に直接アクセスしています。コントローラーは独自の Person クラスを持ち、モデルのすべての Person 属性をコントローラーにコピーし、ビューで上記の構文を使用することができます。しかし、そのデザインには多くの重複があります。助言がありますか？

ちなみにこれはwinformです。モデルは別のプロジェクト/DLL でもあります。DTOとは？

モデルの Person 属性には特別なロジックがあり、ビューで問題が発生することは望ましくありません。たとえば、ビューは次のようになります。

文字列 fn = myController.Firstname;

また、FirstName プロパティのロジックが原因で例外がスローされます。そのため、コントローラーの軽量 (複製) バージョンの Person オブジェクトには、そのプロパティが文字列のみであるため、これらの問題はありません。

また、コントローラーからの非表示の Person プロパティを処理するために、ビューにはモデルへの参照が必要になることにも注意してください。私はそれが気に入りません。

やや典型的な Web アプリケーション用の「ユーザー」オブジェクト モデルを構築したいと考えていますが、オブジェクト モデルとロール システムをどのように設計するのが最善かを判断できません。

基本的に、メンバーシップ プロバイダーのユーザー「ロール」に対応する、約 4 つのユーザー タイプを用意する予定です。

これらのタイプは次のとおりです。 • ワーカー • 雇用者 • ゲスト • 管理者

スーパー タイプは次のとおりです。 • ユーザー

さらに、ユーザーは「労働者」と「雇用者」の両方になる場合があります。

MS ロール & メンバーシップ プロバイダーを使用し、ユーザー ロールに応答するようにナビゲーション UI を設定したいと考えています。

私の質問は次のとおりです。これらのユーザーを柔軟に設計するにはどうすればよいですか (ユーザーは労働者と雇用主になることができます)。ログイン/役割の手順はどのように処理すればよいですか?

（「動作」オブジェクト（労働者の動作、雇用者の動作）のファクトリーを持つユーザーについて考えています）

Login-User ログインの場合、… はそのロールを見つけ、そのサブタイプにキャストします。

これはどのように行われるべきですか？

ドメイン駆動設計で次のパターンが意味があるかどうか知りたいです。

ドメインレイヤーは、モデルとリポジトリで構成されています。アプリケーション層は、ユーザーインターフェイスから、またはModel-View-Controllerパターンのコントローラーからのクエリを処理するサービスで構成されます。

構造の詳細：

特に、メソッドをPhraseエンティティクラスに移動することは理にかなっていますか？その場合、それはどのように呼ばれますか？

編集：

上記の例は、moffdubからの回答とAdeelAnsariからのコメントの後に変更されています。変更が強調表示されます。

追加されたIPhraseRepository.GetPhrase（phraseId）と、それをどのように含めるかについてお聞きしたいのですが。

私はクライアント側で重いWebアプリに取り組んでいます。これは私にとって初めてのことです。私も初めてjQueryを使用しています。クライアント側のコードに、Ajax呼び出しを介してフェッチするモデルデータを追跡させる必要があります。

このデータを保存するための良い方法は何ですか？jQueryは優れたソリューションを提供しますか、それとも優れた汎用Javascriptソリューションがありますか？基本的にJavascriptでモデルクラスを書きたいです（ただし、必ずしも継承は必要ありません）。現在、私のjQueryコードはコントローラーレイヤーであり、DOMとCSSがビューレイヤーを形成しています。他の人はどのようにしてモデルレイヤーを完成させますか？

私は C++ と OpenGL を使用する独自のゲーム エンジンを持っていますが、移動可能な個々のピースを含むモデルがあり、ハードコーディングせずにアニメーション化する方法がわかりません。Ogre などのゲーム エンジンに頼ることなく、スクリプトや IK、またはその他のアニメーション技術を介してソリューションを提供するライブラリはありますか?

MVC を銀行にたとえて説明しているブログ記事を読みました。MVC フレームワーク (CakePHP) を使用した Web アプリケーション開発の経験が数か月あるため、基本は理解できましたが、ロジックを配置する場所に欠陥のあるアプローチを取っていると思わせるテーマが見え始めました。

• ファット モデル、スキニー コントローラ
• モデルにできるだけ多くのビジネス ロジックを保持する

私のアプリでは、モデルは拒食症で、コントローラーは肥満です。コントローラーにはすべてのビジネス ロジックがあり、モデルには関連付けと検証ルール以外には何もありません。

コントローラーをスキャンすると、モデルに含まれるはずの多くのロジックを特定できるようになりました。

• アプリにはアイテムを含むリストがあり、アイテムをランク付けできます。リストをランク順に並べ替えるソートロジックはコントローラーにあります。
• 同様に、アイテム (Item モデル) にもイメージ (Image モデル) があります。各アイテムにはデフォルトの画像があります (items テーブルの image_id で指定)。アイテムが画像とともに表示される場合、デフォルトの画像が最初に表示されます。コントローラーでこれを行うロジックがあります。
• リストが表示されると、関連するリストがサイドバーに表示されます。どのリストが関連しているかを判断するロジックはコントローラーにあります。

今私の質問に：

1. 上記の例で、モデルに属するコントローラーに現在あるロジックのインスタンスであると考えて、正しい方向に進んでいますか?
2. モデルに入れる必要がある、Web アプリに共通のロジックの他の領域は何ですか?
3. この問題を特定し、設計パターンを変更することは、戦いの半分であると確信していますが、上で示した例を取り上げて、そのロジックをモデルに移そうと決めたとしても、どこから始めればよいかわかりません。ここにコードを投稿したり、優れた学習リソースにリンクしたりして、誰かが私を正しい方向に向けることができますか? CakePHP 固有のヘルプは素晴らしいですが、MVC で十分であると確信しています。

以前質問をしたところ、いくつかの素晴らしい回答が得られました。

以前の質問はこちら

そこで与えられたいくつかのアドバイスの裏で、次のコントローラーロジックを動かしてみました

モデルに次のように入力します。

before_save コールバックから呼び出しています。

デフォルトでは、consulted_legal と Consulted_marketing の両方の属性が null ではなく false に設定されています。

例えば。

ただし、このロジックは機能していないようです。オブジェクトを調べると、ステータスが何も設定されていません。なぜこれが起こっているのか誰にもわかりますか？たとえば、モデルで属性が間違ってアクセスされる方法を理解しましたか?

ティア

過去に、ドメインとビューに同じモデル オブジェクトを再利用すべきではないというモデルに関する MVC のアドバイスを読みました。しかし、なぜこれが悪いのかを議論してくれる人を見つけることができませんでした.

ドメイン用とビュー用の 2 つの別個のモデルを作成し、それらの間でマッピングを行うと、多くの重複と、退屈なマッピング コード (一部はAutoMapperなどによって軽減される可能性があります)が作成されるというのが私の意見です。エラーが発生しやすくなります。

2 つの懸念事項に対して個別のモデルを用意することで、コードの重複とマッピングの問題を解決する価値があるのはなぜでしょうか?

LLBLGenを使用してモデルを生成しますが、組み込みの継承ツールを使用するだけで設計の問題を解決したくはありません。OR/Mツールに関係なくモデルに意味を持たせたい。

したがって、アドレスを持つことができるいくつかの異なる種類のエンティティがあり、各エンティティは複数のアドレスを持つことができます（プライマリ、メーリングなど）。

オプション1は、スーパータイプ/サブタイプを使用しています（この種のスキームの正確な名前がわかっている場合は、それが役立ちます）

テーブル：EntityType [EntityTypeID、EntityTypeName]（Say、Company = 1、Employee = 2、AnotherEntity = 3）

エンティティ：[EntityID、EntityTypeID、OriginID]：EntityTypeID => EntityType

会社：[CompanyID、CompanyName、...]

従業員：[EmployeeID、FirstName、...]

AddressType：[AddressTypeID、AddressTypeName]（Say、Primary = 1、Mailing = 2など）

アドレス：[AddressID、AddressTypeID、EntityID、StreetAddress1、...]：AddressTypeID => AddressType、EntityID => Entity

これが機能する方法は、会社または従業員を作成する前に、EntityTypeを適切に入力してEntityレコードを作成する必要があるということです。次に、会社または従業員が作成され、Entity.OriginIDが会社または従業員のIDに設定されます。これで、アドレスレコードは、EntityTypeIDとOriginIDを表示する具体的なエンティティに「関連付けられる」エンティティレコードに属します。

これに必要なすべての参加について少し心配しています。さらに、これが私のORMツール（LLBLGen）では不格好になるのではないかと少し心配しています。

オプション2、これはオプション1の一種のテイクです。おそらくもっと悪いと思いますが、それを含めると同じです。

テーブル：

EntityType：[EntityTypeID、EntityTypeName]（Say、Company = 1、Employee = 2、AnotherEntity = 3）

エンティティ：[EntityID、EntityTypeID]：EntityTypeID => EntityType

会社：[CompanyID、EntityID、CompanyName、...]：EntityID => Entity

従業員：[EmployeeID、EntityID、FirstName、...]：EntityID => Entity

AddressType：[AddressTypeID、AddressTypeName]（Say、Primary = 1、Mailing = 2など）

アドレス：[AddressID、AddressTypeID、EntityID、StreetAddress1、...] AddressTypeID => AddressType、EntityID => Entity

これはオプション1と同様に機能し、会社または従業員の場合、エンティティレコードが最初に作成され、EntityTypeが適切に設定されます。次に、CompanyまたはEmployeeレコードが作成され、以前に作成されたEntityレコードのEntityIDがCompanyまたはEmployeeレコード自体に設定されます。アドレスはエンティティ自体に関連付けられます。ただし、これはAddressレコードをCompanyおよびEmployeeレコードのように扱うため、奇妙に思えます。つまり、EntityIDを保持していますが、その参照は、CompanyテーブルおよびEmployeeテーブルでEntityIDが参照するものとは異なる意味を持ちます。

これは少し悪いようです。最初の問題とほぼ同じ問題がありますが、スキーマの直感性が低下することもあると思います。

どちらの場合も、CompanyテーブルなどのいくつかのUnique制約を使用する必要があります（EntityIDはCompanyテーブルで一意である必要があります）。ただし、会社と従業員のレコードが同じエンティティレコードを指さないようにするには、他のプログラムによるチェックを行う必要があります。LLBLGenのようなツールが、EntityTypeID値をインテリジェントに処理することにより、オプション1で「魔法」を実行できるかどうかはわかりません。

したがって、オプション3は単純です。

テーブル：

会社：[CompanyID、CompanyName、...]

従業員[EmployeeID、FirstName、...]

AddressType：[AddressTypeID、AddressTypeName]（Say、Primary = 1、Mailing = 2など）

CompanyAddress：[CompanyAddressID、AddressTypeID、CompanyID、StreetAddress1、...]：AddressTypeID => AddressType、CompanyID => Company

EmployeeAddress：[EmployeeAddressID、AddressTypeID、EmployeeID、StreetAddress1、...]：AddressTypeID => AddressType、EmployeeID => Employee

これにより、結合の処理がはるかに簡単になります。しかし、これは実際には実行可能ではないと思います。私にはたくさんの実体があります。私は多くのエンティティを持っているだけでなく、アドレスを持つことができる多くのエンティティを持っています。また、この「アドレス」はほんの一例です。アドレスに似たものが他にもたくさんあります。これらすべての人のためにテーブルを作成することは、開発の面で非常に拡大するとは思いません。また、ORMにコードを使用して、すべての異なるアドレスを同じベース「アドレス」タイプとして処理させることができると確信していますが、ORMが実行できるトリックに依存したくありません。

それで、このスーパータイプ/サブタイプのものは良い考えですか（私はそうではないと思います）？もしそうなら、それについて行くより良い方法はありますか？そうでない場合、より良い選択肢は何ですか。