问题标签 [model]

我有一个 Rails 模型可以验证 2 个表单值的唯一性。如果这 2 个值不是唯一的，则会显示验证错误，并且“提交”按钮更改为“重新提交”。我想允许用户单击“重新提交”按钮并绕过模型验证。我想从 Rails 验证文档中做这样的事情：

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

但是我的模型中没有可以检查的值……只有具有“重新提交”值的参数。

关于如何做到这一点的任何想法？

我在模型中有一个 Person 类，并希望将其 15 个属性分配给视图中的标签。视图不应访问模型。这意味着控制器将处理创建人。View 是如何从 Controller 中获取这些 Person 属性的呢？如果 Controller 包含 Type Person 的成员，则 View 可以执行以下操作：

lblFirstName.Text = theController.Person.FirstName;

lblLastName.Text = theController.Person.LastName;

lblCity.Text = theController.Person.City;

但是，View 仍然是直接访问 Model（即 Person）。Controller 可以有自己的 Person 类，将 Model 的所有 Person 属性复制到其中，并具有上面的 View 使用语法。但这种设计有很多重复之处。有什么建议么？

顺便说一句，这是一个winform。该模型也是一个单独的项目/DLL。什么是 DTO？

Model 中的 Person 属性有特殊的逻辑，我不希望 View 遇到问题。例如，视图可能会：

字符串 fn = myController.Firstname;

并且由于 FirstName 属性中的逻辑而引发异常。因此，Person 对象的 Controller 轻量级（重复）版本不会有任何这些问题，因为它的属性只是字符串。

另请注意，您的 View 将需要对 Model 的引用来处理来自 Controller 的隐藏 Person 属性。我不喜欢它。

我想为一个有点典型的 Web 应用程序构建一个“用户”对象模型……但是我无法决定如何最好地设计对象模型和角色系统。

基本上我计划有大约 4 种用户类型……它们对应于会员提供者中的用户“角色”。

这些类型将是： • 工人 • 雇主 • 访客 • 管理员

超级类型是： • 用户

此外，用户有时可能既是“工人”又是“雇主”。

我想使用 MS Roles & Membership 提供程序并设置导航 UI 以响应用户角色。

我的问题是：我怎样才能最好地将这些用户设计为灵活（用户可以是工人和雇主）。如何处理登录/角色程序？

（我正在考虑一个拥有“行为”对象工厂的用户（工人行为，雇主行为））

For Login-User logins in ... 找到它的角色并转换到它的子类型。

这是应该怎么做的吗？

我想知道您是否发现以下模式在域驱动设计中有意义。

领域层由模型和存储库组成。应用层由处理来自用户界面或模型-视图-控制器模式中控制器的查询的服务组成。

结构细节：

特别是，将方法移动到 Phrase 实体类中是否有意义？那样的话，怎么称呼？

编辑：

上面的示例在 moffdub 的回答和 Adeel Ansari 的评论后进行了修改。更改突出显示。

我想问一下添加的 IPhraseRepository.GetPhrase(phraseId) 以及如何包含它？

我正在开发一个客户端很重的网络应用程序，这对我来说是第一次。我也是第一次使用 jQuery。我需要让我的客户端代码跟踪它通过 Ajax 调用获取的模型数据。

存储这些数据的好方法是什么？jQuery 是否提供了一个好的解决方案，还是有一个好的通用 Javascript 解决方案？我基本上想用Javascript编写模型类（但我不一定需要继承）。现在我的 jQuery 代码是一个控制器层，DOM 和 CSS 构成了我的视图层。其他人如何完成模型层？

我有自己的使用 C++ 和 OpenGL 的游戏引擎，但我有带有可以移动的各个部分的模型，我不确定如何在不对其进行硬编码的情况下对其进行动画处理。是否有任何库可以通过脚本或 IK 或其他动画技术提供解决方案，而无需借助 Ogre 等游戏引擎？

我刚刚阅读了一篇博客文章，该文章用银行类比解释了 MVC。我有几个月的使用 MVC 框架（CakePHP）开发 Web 应用程序的经验，所以我掌握了基础知识，但我开始看到一个主题，让我认为我在放置逻辑的地方采用了一种有缺陷的方法：

• 胖模型，瘦控制器
• 在模型中保留尽可能多的业务逻辑

在我的应用程序中，模型患有厌食症，而控制器则肥胖。我在控制器中有所有业务逻辑，除了模型中的关联和验证规则之外什么都没有。

扫描我的控制器，我现在可以识别出很多应该包含在模型中的逻辑：

• 该应用程序具有包含项目的列表，并且可以对项目进行排名。将列表按排名顺序排列的排序逻辑位于控制器中。
• 同样，物品（Item model）也有图像（Image model）。每个项目可能有一个默认图像（由项目表中的 image_id 指定）。当一个项目与它的图像一起显示时，默认图像应该首先出现。我有在控制器中执行此操作的逻辑。
• 显示列表时，侧栏中会显示相关列表。确定哪些列表相关的逻辑在控制器中。

现在我的问题：

1. 通过上面给出的示例，我认为这些是当前属于模型的控制器中的逻辑实例，我是否走在正确的轨道上？
2. Web 应用程序共有的其他一些逻辑领域应该纳入模型中吗？
3. 我确信发现这个问题并改变我的设计模式是成功的一半，但即使我决定采用上面给出的那些例子并尝试将这种逻辑转移到模型中，我也不知道从哪里开始。任何人都可以通过在此处发布一些代码或链接到一些好的学习资源来为我指明正确的方向吗？CakePHP 的特定帮助会很棒，但我确信任何 MVC 都足够了。

我之前问了一个问题，引起了一些很好的反应。

这是之前的问题

根据那里给出的一些建议，我尝试移动以下控制器逻辑

进入模型，如下所示：

我从 before_save 回调中调用它。

默认情况下，consulted_legal 和consulted_marketing 属性都设置为false 而不是null，这就是为什么我在这里测试== false 或true，而不是询问

例如。

但是，这种逻辑似乎不起作用。如果我检查该对象，则永远不会将状态设置为任何内容。谁能发现为什么会发生这种情况？例如，我是否知道模型中的属性是如何被错误访问的？

TIA

我过去读过一些关于模型的 MVC 建议，指出您不应该为域和视图重用相同的模型对象；但我找不到任何愿意讨论为什么这很糟糕的人。

我认为创建两个单独的模型——一个用于域，一个用于视图——然后在它们之间进行映射会产生很多重复，加上繁琐的映射代码（其中一些可能会被AutoMapper之类的东西缓解），这很可能容易出错。

是什么让为这两个问题建立一个单独的模型值得重复和映射代码的麻烦？

我将使用 LLBLGen 来生成模型，但是我不想只使用它所拥有的任何内置继承工具来解决我的设计问题。无论 OR/M 工具如何，我都希望模型有意义。

所以，我有几种不同类型的实体，它们可以有地址，每个实体都可以有多个地址（主要地址、邮寄地址等）。

选项 1，使用超类型/子类型（如果您知道此类方案的确切名称，那将很有帮助）

表：EntityType [EntityTypeID, EntityTypeName]（例如，Company=1，Employee=2，AnotherEntity=3）

实体：[EntityID，EntityTypeID，OriginID]：EntityTypeID=>EntityType

公司：[公司 ID、公司名称、...]

员工：[员工ID，名字，...]

AddressType：[AddressTypeID, AddressTypeName]（例如，Primary=1，Mailing=2 等）

地址：[AddressID, AddressTypeID, EntityID, StreetAddress1, ...] : AddressTypeID=>AddressType, EntityID=>Entity

这样做的方式是，在创建任何 Company 或 Employee 之前，必须创建一个 Entity 记录并正确填写 EntityType。然后创建 Company 或 Employee 并将 Entity.OriginID 设置为 Company 或 Employee 的 ID。现在，地址记录将属于实体记录，这些记录将“绑定”到具体实体查看 EntityTypeID 和 OriginID。

我有点担心这需要的所有连接。更重要的是，我有点担心这在我的 ORM 工具 (LLBLGen) 中会很笨拙。

选项 2，这是对选项 1 的一种看法。我认为可能更糟，但包括它是一样的：

表：

EntityType：[EntityTypeID, EntityTypeName]（比如，Company=1，Employee=2，AnotherEntity=3）

实体：[EntityID，EntityTypeID]：EntityTypeID=>EntityType

公司：[CompanyID, EntityID, CompanyName, ...] : EntityID=>Entity

员工：[EmployeeID，EntityID，FirstName，...]：EntityID=>Entity

AddressType：[AddressTypeID, AddressTypeName]（例如，Primary=1，Mailing=2 等）

地址：[AddressID, AddressTypeID, EntityID, StreetAddress1, ...] AddressTypeID =>AddressType, EntityID=>Entity

这将类似于选项 1，因为对于公司或员工，将首先创建实体记录，并适当地设置实体类型。然后，将创建 Company 或 Employee 记录，并且先前创建的 Entity 记录的 EntityID 将设置在 Company 或 Employee 记录本身上。该地址将与实体本身相关联。然而，这似乎很奇怪，因为这会将地址记录视为公司和员工记录，即它们持有一个实体ID，但该引用意味着与公司和员工表中实体ID 引用的不同。

这似乎有点糟糕。它与第一个问题几乎相同，但我认为它也使模式不那么直观。

在这两种情况下，您都需要使用一些 Unique 约束，例如在 Company 表中（EntityID 在 Company 表中应该是唯一的）。但是，您需要执行一些其他程序检查以防止公司和员工记录指向相同的实体记录。我不知道像 LLBLGen 这样的工具是否可以通过智能地处理 EntityTypeID 值来对选项 1 执行任何“魔术”。

因此，选项 3 很简单：

表：

公司：[公司 ID、公司名称、...]

员工 [EmployeeID, FirstName, ...]

AddressType：[AddressTypeID, AddressTypeName]（例如，Primary=1，Mailing=2 等）

CompanyAddress: [CompanyAddressID, AddressTypeID, CompanyID, StreetAddress1, ...] : AddressTypeID=>AddressType, CompanyID=>Company

EmployeeAddress: [EmployeeAddressID, AddressTypeID, EmployeeID, StreetAddress1, ...] : AddressTypeID=>AddressType, EmployeeID=>Employee

这使得连接更容易处理。但是，我不认为这真的可行。我有很多实体。我不仅有很多实体，而且我有很多可以有地址的实体。另外，这个“地址”只是一个例子，我还有很多其他类似于地址的东西。我不认为为每个人创建一个表格会在开发方面进行扩展。另外，我确信我可以让我的 ORM 让我使用代码将所有不同的地址视为相同的基本“地址”类型，但是，我不想依赖 ORM 可以做的技巧。

那么，这种超类型/子类型的东西是个好主意吗（我怀疑不是）？如果是，是否有更好的方法来解决它。如果没有，有什么更好的选择。