翻译
文章平均质量分 77
gj2233
这个作者很懒,什么都没留下…
展开
-
领域驱动设计之代码优先-领域层设计-6 (翻译)
3.2.- 使用实体框架的领域实体 EF 4.1提供了下面的选则来实现实体:- 按照模型优点或者数据库优先的方法:o 指令性实体(于EF的基类和实体对象模板耦合)需要使用部分类来添加实体逻辑。o 自跟踪实体连上基于对象上下文的环境,需要使用部分类来添加实体逻辑。o POCO实体连上基于对象上下文的环境,需要使用部分类来添加实体逻辑翻译 2013-03-21 10:07:52 · 1127 阅读 · 0 评论 -
领域驱动设计之代码优先-领域层设计-4 (翻译)
2.4.- 领域层设计的注意事项 当设计领域子层时,软件架构的主要目标应该是最小化复杂性,把不同的任务分到不用的地方。我们在每个地方设计的组件都应该针对该特定区域,不应该包含其他区域的相关代码。 在设计业务层时下面的准则应该考虑到:- 定义不同种类的领域组件:按照需求实现不同类型的模式总是一个好注意。这会增加代码的可维护性和可重用性。例如,我们可以定义领翻译 2013-03-21 10:06:18 · 806 阅读 · 0 评论 -
领域驱动设计之代码优先-领域层设计-3 (翻译)
2.3.- 工场模式 当创建一个对象或整个聚合时,会变得复杂或揭示了太多的内部结构,工厂提供了封装。创建其它对象的程序元素叫做工厂。 如果创建的对象并不简单或者需要要做很多验证,在创建期间检查一些对象,建议使用工厂来创建对象。 另一方面,如果创建对象很简单,使用构造器或者控制反转/依赖注入容器足够创建对象的依赖。 我们可以使用这个模式不意味翻译 2013-03-21 10:04:12 · 1028 阅读 · 0 评论 -
领域驱动设计之代码优先-架构描述 (翻译)
Microsoft – Spain团队有一个很不错的“面向领域多层分布式项目”案例:Microsoft – Domain Oriented N-Layered .NET 4.0 App Sample(在本系列文章中,我使用NLayerApp作为该项目的名称进行介绍),在codeplex上的地址是:http://microsoftnlayerapp.codeplex.com/。它是学习领域驱动设计(翻译 2013-03-16 15:40:13 · 3789 阅读 · 2 评论 -
领域驱动设计之代码优先-领域层设计-11 (翻译)
3.16.- 实现值对象 值对象有下面的特征:- 没有标识符的概念- 有相同值的两个值对象视为相等- 不可变 一个值对象其实是一组属性。一个简单的.NET值对象可能如下。它还和EF代码优先不兼容,因为它像一个复杂类型。注意我们怎样使它有不可变的特征。这可以初始化它的属性,之后它的属性就不能从外部修改://Sample .NET VALU翻译 2013-03-21 10:12:11 · 653 阅读 · 0 评论 -
领域驱动设计之代码优先-领域层设计-9 (翻译)
3.11.- ‘Fluent API’和领域实体 我们应该使用代码优先‘Fluent API’来改变/自定义实体映射,然而,它必须重写DbContext方法。特别地,我们必须重写”DbContext OnModelCreating()‟方法。这是数据持久化层的部分,所以我们会在那章中解释如何使用。关于领域驱动设计和持久化透明原则的重要主要事项: “数据注解”翻译 2013-03-21 10:10:28 · 670 阅读 · 0 评论 -
领域驱动设计之代码优先-领域层设计-5 (翻译)
3.1.- 实现领域实体 第一步我们要选择实现领域实体的技术。实体用来保存和管理应用中的主要数据和逻辑。简言之,领域实体包含并通过属性来获得值,同时也可以有实体内部业务逻辑的类。 下面的子图我们着重了领域层中实体的位置:决定是否什么类型的数据/技术作为领域实体是非常重要的因为这影响了一些方面,例如这些问题:- 领域层是否独立于数据访问技翻译 2013-03-21 10:07:00 · 966 阅读 · 0 评论 -
领域驱动设计之代码优先-领域层设计-1 (翻译)
1.- 领域 本节描述了领域逻辑层的架构和设计领域层时需要考虑的重要准则。 领域层负责展示业务,业务流程的状态和领域规则的实现。也应该包括反映业务流程的状态,甚至当技术存储的细节交给较低层的基础设施(仓储库等)时。 ”领域模型“层是软件的核心。 该层的足见实现了系统的核心功能并封装了所有相关的业务逻辑(在DDD术语中通常叫领域逻辑)。一般的,领域层通常包含实现领域逻翻译 2013-03-16 14:26:58 · 1516 阅读 · 1 评论 -
领域驱动设计之代码优先-领域层设计-2 (翻译)
2.2.- 领域层的要素 在本章,我们简单解释每种元素的职责: 2.2.1.- 领域实体 这个概念代表了实体模式的实现。 实体表示领域对象,主要由对象的标识和连续性定义,并不只是由组成对象的属性定义。 实体一般和主要的业务/领域对象有一个直接的关系,例如客户,雇员,订单等等。因此,把这些实体保存到数据很正常,虽然这完全取决于每一个具体应用。虽然不是强制的,但是“连翻译 2013-03-21 10:03:37 · 1226 阅读 · 1 评论 -
领域驱动设计之代码优先-领域层设计-10 (翻译)
3.14.- 创建POCO代理 如果想要启用POCO实体的延迟加载和实体框架跟踪类的变化,你的POCO类必须满足该主题的需求,这样实体框架就可以在运行时创建POCO实体的代码。代理类从你的POCO类型中派生、3.14.1.- POCO实体类定义的需求 如果类满足下面描述的实体框架会创建POCO实体的代理。POCO实体可以有支持改变跟踪或延迟加载的代理对象。你可以翻译 2013-03-21 10:11:36 · 717 阅读 · 0 评论 -
领域驱动设计之代码优先-领域层设计-7 (翻译)
3.6.- 实体类的领域逻辑(非贫血领域) 在领域驱动设计中需要把逻辑关联到实体的内部操作中。如果实体类只是用来数据结构,所有的领域逻辑都放在领域服务中,这会构成一个反模式叫做”贫血领域模型“。见http://www.martinfowler.com/bliki/AnemicDomainModel.html 该反模式解释了对于面向领域应用,实体模型不应包含数据。这个翻译 2013-03-21 10:08:47 · 900 阅读 · 0 评论 -
领域驱动设计之代码优先-领域层设计-8 (翻译)
3.9.- 领域实体的”数据注解“ 目前为止我们让EF使用默认的协定发现模型,但有时候当我们的类不按照协定,我们需要进行更多的配置。就像我们提到的,有两个选择;我们先看数据注解然后看”Fluent API“。 假设我们的BankAccount实体的Id属性不是”BankAccountId‟而是叫做“BankAccountNumber‟的属性。我们试着运行应用但会得到I翻译 2013-03-21 10:09:58 · 962 阅读 · 0 评论