asp.net – 哪种模式最匹配场景详细,是不是很好的做法？

发布时间：2020-12-16 03:20:34 所属栏目：asp.Net 来源：网络整理

导读：在过去的几年里,我已经看过几次特定的模式.请让我描述一下. 在UI中,每个新记录(例如,新客户详细信息)存储在表单上而不保存到数据库.这显然已经完成,因此不会使数据库混乱或导致不必要的数据库命中. 在UI状态下,使用Guid识别这些对象.当这些保存到数据库时,不

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

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

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

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

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

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

解决方法

这里有几种模式.

Identity Field Pattern

在EAA的P中定义为“在对象中保存数据库ID字段以维护内存中对象和数据库行之间的标识”.这部分很明显.

Transaction Script和Metadata Mapping

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

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

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

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

好的还是坏的做法？

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

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!