哪种模式最接近匹配情景详细,这是一种好的做法？

Question

在过去的几年里,我已经看过几次特定的模式.请让我描述一下.

在UI中,每个新记录(例如,新客户详细信息)都存储在表单上而不保存到数据库.这显然已经完成,因此不会使数据库混乱或导致不必要的数据库命中.

在UI状态下,使用Guid识别这些对象.当这些保存到数据库时,不会存储其关联的Guids.相反,它们被分配了一个数据库Int作为其主键.

表单可以处理来自数据库的检索项目(使用Int)以及尚未提交的项目(使用Guid)的混合.

在检查表单(使用Firebug)以查看使用了哪个密钥时,我们发现使用了两部分分隔的组合密钥.第一部分是guid(如果从数据库中绘制,则为空guid),第二部分是整数(如果未从数据库中绘制,则存储零).由于组合键的一部分将始终唯一地标识记录,因此它工作得相当好.

这是好习惯吗？任何人都可以告诉我模式名称或建议一个如果它还没有命名？

Answer 1

这里有几种模式在起作用。

身份字段模式

在 EAA 的 P 中定义为“在对象中保存数据库 ID 字段，以维护内存中对象和数据库行之间的标识。 ”这部分是显而易见的。

事务脚本和元数据映射

通常，ASP.NET DataBound 控件将事务脚本模式与元数据映射模式结合使用。Fowler 将元数据映射定义为“在元数据中保存对象关系映射的详细信息”。如果您曾经编写过数据源控件，那么此模式的元数据映射方面似乎是显而易见的。

事务脚本模式“通过过程组织业务逻辑，其中每个过程处理来自演示文稿的单个请求”。为了封装维护表示状态和数据状态的逻辑，中间对象必须指示：

1. 如果数据库记录存在
2. 如何识别后端数据记录，填充UI控件
3. 如果当前没有数据记录，如何识别数据和UI控件，以便可以从后端数据存储更新演示数据。

Guid新客户端数据条目和数据记录ID的存在integer提供了足够的信息，只需对数据库进行一次调用即可确定所有这些。这可以通过仅使用整数来完成（并且可能为每个非持久化 UI 数据项提供唯一的负整数），但拥有两个单独的字段可能更明确。

好的做法还是坏的做法？

这取决于。ASP.NET 是一个非常成功的软件项目，并且这种模式似乎始终有效。然而，这种类型的 ASP.NET Web 控件具有非常特定的应用范围 - 通过简单的映射来封装 UI 和数据库之间有关数据对象的交互。这些担忧似乎确实有点模糊，但对于许多适用的场景来说，这仍然是可以接受的。只要行数据网关可接受，该模式就有效。如果有多个数据库行受 Web 控件影响，则此方法将不起作用。在这些更复杂的情况下，Active Record实现或域模型和存储库实现的组合会更适合。

一种模式是好还是坏实践实际上取决于它的应用场景。人们似乎倾向于提倡更复杂的设计结构，因为它们可以应用于更多场景而不会失败。 然而，在数据记录和 UI 之间直接映射的非常简单的应用程序中，此模式非常有用，因为它可以创建预期结果，同时最大限度地减少性能和开发开销。