asp.net - 哪种模式最匹配详细的场景，这是一种很好的做法吗？

Question

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

在 UI 中，每条新记录(例如，新客户详细信息)都存储在表单中，而无需保存到数据库中。这显然已经完成，因此不会使数据库困惑或导致不必要的数据库命中。

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

该表单可以处理从数据库中检索到的项目(使用 Int)以及尚未提交的项目(使用 Guid)的混合。

在检查表单(使用 Firebug)以查看使用了哪个键时，我们发现使用了由两部分分隔的组合键。第一部分是 guid(如果从数据库中提取则为空 guid)，第二部分是整数(如果不是从数据库中提取则存储零)。由于组合键的一部分将始终唯一标识一条记录，因此效果很好。

这是好的做法吗？任何人都可以告诉我模式名称或建议一个如果它尚未命名吗？

Answer 1

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

Identity Field Pattern

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

Transaction Script和 Metadata Mapping

一般来说，ASP.NET DataBound 控件使用类似 的东西。交易脚本 图案与 一起使用元数据映射图案。 Fowler 将元数据映射定义为“在元数据中保存对象关系映射的细节”。如果您曾经编写过数据源控件，那么这种模式的元数据映射方面似乎很明显。

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

如果存在数据库记录

如何识别后端数据记录，填充UI控件

如果没有当前数据记录，如何识别数据和 UI 控件，以便可以从后端数据存储更新演示数据。

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

好还是坏的做法？

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

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