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

Question

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

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

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

表单可以处理来自数据库的已检索项目的混合（使用Int）以及尚未提交的项目（使用Guid）。

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

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

Answer 1

这里有几种模式。

Identity Field Pattern

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

Transaction Script和Metadata Mapping

通常，ASP.NET DataBound控件使用类似事务脚本模式的内容以及元数据映射模式。 Fowler将元数据映射定义为“保存元数据中对象关系映射的详细信息”。如果您曾编写过数据源控件，则此模式的元数据映射方面似乎很明显。

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

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

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

好或坏的做法？

这取决于。 ASP.NET是一个非常成功的软件项目，这种模式似乎始终如一。但是，这种类型的ASP.NET Web控件具有非常特定的应用程序范围 - 使用简单映射封装UI和数据库之间关于数据对象的交互。这些担忧似乎有点模糊，但对于许多适用的情况，这仍然是可以接受的。只要Row Data Gateway可以接受，该模式就有效。如果受Web控件影响的数据库行不止一个，则此方法将不起作用。在这些更复杂的情况下，Active Record实施或Domain Model和Repository实施的组合更适合。

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

Answer 2

我认为没有具体的模式。

这是好的做法吗？我不这么认为。首先，它不是面向对象的。怎么样：

interface ICommittable
{
    /// <summary>
    /// Gets or sets a value indicating whether the entity was already committed to the database.
    /// </summary>
    bool IsCommitted;

    /// <summary>
    /// Gets or sets the ID of the entity, used either in database or generated by UI or an underlying BL.
    /// </summary>
    Guid Id;
}

相反，他们所做的是以一种非显而易见的方式在一个中混合三个单独的数据条目：

• ID
• 另一个ID（为什么？）
• 该实体是否已承诺的事实。

特别是，拥有两个单独的ID非常令人困惑，不仅需要一个好的文档，还需要一些时间让新开发人员了解这里发生的事情。

如果目的是创建新实体而不向数据库查询新ID，他们可以在任何地方使用GUID：当创建新实体时，您Guid.CreateNew它的ID，然后，如果需要，您提交所有内容，这个GUID也是数据库中的标识符（已经保存的GUID和新的GUID之间几乎没有机会发生冲突，所以我不关心这个。）

更简单，不是吗？

做一些事情也不容易。例如，您如何比较两个实体？请记住：

• 具有不同GUID的两个已提交实体不相等，
• 具有不同ID的两个未提交的实体不相等，
• 已提交的实体可能等同于未提交的实体，即使其和其ID 的GUID
也不同。

总而言之，似乎缺乏重构。可能他们正在修改一个项目，其中实体已经通过他们的id (int)唯一键在数据库中被识别出来，因此他们只是添加了GUID而不是重构它们，从而制定了整体：

• 更难理解，
• 将来很难合作和修改。

Answer 3

如果我没错，那就是存储库模式：http://martinfowler.com/eaaCatalog/repository.html

这在Evans Domain Driven Design一书中得到了很好的描述，并且已经证明在特定情况下运行良好。