domain-driven-design – 持久性模型和域模型之间的映射
我已经完成了关于域驱动设计的IMMENSE阅读量,并且使用该设计完成了一些相当复杂的项目.所有这些都有他们的缺陷和反模式,沿途实现.可以理解,因为这是一个学习过程.但是,我仍然坚持一个我似乎无法通过谷歌解决的主要概念(也许我只是没有提出正确的搜索条件)或者我自己的反复试验.
我已经阅读了几篇强调声称保持域模型和持久性模型分离的文章.除非ID具有域用途,否则不要让ID之类的内容泄漏到您的域模型中.根据该政策,如何在实践中坚持域模型?我读过的所有文章都在摘要中讨论这个问题,但我找不到一个不违反这个问题的具体例子. 我有一个相对庞大而复杂的Web应用程序,我正在构建并希望实现“最佳”域和持久性分离.我正在使用手动ORM(是的,是的,我知道 – 我不应该 – 等等等等 – 但是,基础表和查询太复杂了,不能使用像EF或NHibernate这样的东西).在大学的这个会计软件包中,我有总帐日记帐分录,结构如下: Public Class Journal Public Property AccountCode As SFSAccountCode = Nothing Public Property Amount As Decimal = 0 Public Property BudgetCategory As BudgetCategory = Nothing Public Property [Date] As DateTime = Nothing Public Property ChildAccount As ChildAccount = Nothing Public Property Description As String = "" Public Property FiscalYear As SFSFiscalYear = Nothing Public Property Fund As Fund = Nothing Public Property JournalID As Int32 = -1 Public Property Notes As String = "" Public Property Program As String = "" Public Property Source As JournalSource = Nothing Public Property Status As JournalEntryStatus = JournalEntryStatus.Open Public Property TransactionType As TransactionType = Nothing End Class 如果不包含uniqueID(JournalID),如何将域模型中的实例映射到持久性模型中的实例?根据我的理解,您将通过其不变量来考虑唯一的对象.如果您的对象只有一个或两个属性作为字符串或整数,则很容易.我显然有许多属性,其中有几个是域模型本身. 我确信有一些我错过的关键概念 – 任何人都可以指向一个资源(具体代码为奖励!)来帮助解释如何在没有数据库ID的持久模型与域模型之间进行映射? 顺便说一句,我知道我的属性应该是私有集合,用于良好的域设计.他们将有一次我可以更好地找出持久性和域之间的映射.我碰巧在VB.NET中编写代码但可以读取Java或C#,因为我确信大多数示例都是这两种语言中的一种. 解决方法
根据Domain Driven Design:
关于实体和价值观的一些话 有权限对象(实体)和值对象(值).值由一组值(或字段)标识.因此,如果我们有两个具有相同字段的值对象,它们对我们来说并不是不可分割的(作为现实生活中的模型).值对象通常是不可变的. 实体对象不由包含的值标识.实体对象由其自身唯一的存在来标识.我们不能说两个同名的人提出单身真人. 例如: class ProductAmountPair { public Product Product { get; set; } public int Amount { get; set; } } class Order { public int Id; public IList<ProductAmount> { get; set; } } ProductAmount是一个值,Order是一个实体(实际上它取决于具体情况). 要识别实体对象,有必要确定一些唯一值(键).在某些域中,密钥是从外部给出的(来自现实生活),但是另外一些密钥需要生成密钥,因此应用程序本身定义了一种方法. 因此,结论是:对于实体,我们必须引入关键字段来识别它们.这是必要的,因为实体不能通过它们包含的一组值来识别. 数据库 好的,数据库及其角色怎么样? 今天,数据库不仅仅是数据存储,而且是用于确保数据完整性,事务处理等的复杂机制.通常,复杂的任务(如并发访问)仅通过将它们“广播”到数据库来解决. 出于同样的原因,数据库通常用于生成关键值,它们提出了获得新的唯一值的良好可靠机制. 可以说,数据库引擎需要为每个表创建主键,因此域中的每个类都应该具有键字段,因此它是实体.但: >关系数据库引擎使用主键进行引用,不应以任何方式影响域模型 坚持和领域 在谈论域时,我们为什么要考虑数据库(甚至关系数据库!)?在他的DDD书中,埃里克埃文斯说“不要面对技术和范式”. 有时,由于强大的性能或可靠性要求,我们必须放弃一些DDD纯度和清晰度,并使域模型更多(例如)“关系”(我的意思是大多数类表映射). 我们只需处理它. 出于同样的原因,我们可以承认实体关键领域的部分“技术”角色.但我们也承认其主要作用是域名识别属性. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |