博客园-dax.net-最新评论

Re:EntityFramework之领域驱动设计实践【后续篇】：基于EF 4.3.1 Code First的领域驱动设计实践案例

Cheney|采泥 — Thu, 03 May 2012 14:47:35 GMT

请问关于xsd文件，你一开始说是手写的，后来又说是为了方便第三方工具设计。我想知道到底是什么第三方工具，因为我用VS的xsd设计器根本生成不出这种格式的文件

Cheney|采泥 2012-05-03 22:47 发表评论

Re:EntityFramework之领域驱动设计实践【后续篇】：基于EF 4.3.1 Code First的领域驱动设计实践案例

dax.net — Wed, 02 May 2012 11:02:49 GMT

[quote]fanfree： @dax.net [quote]dax.net： [quote]Lonwern：看了下代码，数据查询用了Specification模式，导致调用的方法是IEnumerable的Where(Func)而不IQueryable的Where(Expression>)，也就是把整个表的数据读到内存再重新筛选。[/quote] [b]这样，将EntityFrameworkRepository类修改一下，在DbSet的Where调用时，不要使用specification.IsSatisfiedBy，而直接使用speci...[/quote] [b]如果在Where中使用Specification.IsSatisfiedBy，那么就会使用参数为一个Func委托的Where重载，而这个重载返回的是一个IEnumerable的对象，这样就会导致后续的操作比如排序等就会在内存中执行，而不是数据库端。[/b]

dax.net 2012-05-02 19:02 发表评论

Re:EntityFramework之领域驱动设计实践【后续篇】：基于EF 4.3.1 Code First的领域驱动设计实践案例

fanfree — Wed, 02 May 2012 09:12:46 GMT

@dax.net [quote]dax.net： [quote]Lonwern：看了下代码，数据查询用了Specification模式，导致调用的方法是IEnumerable的Where(Func)而不IQueryable的Where(Expression>)，也就是把整个表的数据读到内存再重新筛选。[/quote] [b]这样，将EntityFrameworkRepository类修改一下，在DbSet的Where调用时，不要使用specification.IsSatisfiedBy，而直接使用specification.GetExpression()即...[/quote] 这里有些不明白，能否说明下[b]Specification导致IEnumerable[/b]的原因；谢谢

fanfree 2012-05-02 17:12 发表评论

Re:领域驱动设计系列文章汇总

ibbcall — Mon, 30 Apr 2012 10:12:09 GMT

@dax.net 谢谢楼主的回答。很清楚。还有一个疑问：为什么不能用数据库的主键作为实体的ID？

ibbcall 2012-04-30 18:12 发表评论

Re:EntityFramework之领域驱动设计实践【后续篇】：基于EF 4.3.1 Code First的领域驱动设计实践案例

Kain — Sat, 28 Apr 2012 04:55:18 GMT

[quote]dax.net： [quote]Kain：不知道怎么处理比较复杂的权限过滤的问题？例如根据权限查看特定类型的订单？[/quote] [b]这个问题三言两语估计也讨论不清楚。请参考：[/b][url=http://www.utwente.nl/ewi/trese/graduation_projects/2008/Uithol.pdf]http://www.utwente.nl/ewi/trese/graduation_projects/2008/Uithol.pdf[/url][/quote] 这个问题确实比较复杂，受限于以前的一些设计思想局限，一时找不到方向。

Kain 2012-04-28 12:55 发表评论

Re:【领域驱动设计】浅谈聚合的划分与设计

dax.net — Sat, 28 Apr 2012 02:10:36 GMT

[quote]ibbcall： @八匹马我倒认为DDD也可以解决您遇到的问题，DDD是一种思考问题的方式。您可以把信息可以扩展这个用户需求，不先从数据库角度考虑，把他当成是一个领域问题，从领域模型中去解决这个问题，之后再考虑领域模型持久化到数据库的问题。用DDD方式开发的前期投入是比较大的，对开发、设计人员要求要高一些，设计合理的话，后期的维护量反而不大。[/quote] [b]是的，所以在国内很少有企业或单位去实践DDD。这是一部分原因。由此引申的另一部分原因就是，DDD更适合大型企业级应用，而国内绝大部分项目都达不到这样的规模，因此投入大量的人力物力去实践DDD就显得特2.[/b]

dax.net 2012-04-28 10:10 发表评论

Re:领域驱动设计系列文章汇总

dax.net — Sat, 28 Apr 2012 02:00:54 GMT

[quote]ibbcall：有几个DDD方面的问题请教楼主，问题如下： 1. 如果把值对象中的属性通过readonly或其他形式定义成只读的，是否无法使用EF或NHibernate等ORM工具？ 2. 现有的ORM工具更多的是考虑编码效率，是为了减少编码量，把一个映射看成是机械形式的。而现实中如果已经有一个在线运行的数据库，在此基础上构建领域模型，会有不少设计会受限于ORM工具，我们有部分持久化和反持久化工作是通过手工代码实现的，因为我认为保持最小技术因素领域模型是值得的。您怎样看这件事情？目前是否有半手工实现的ORM工具？ 3. 实体对象ID在我们系统中是通过Oracle数据库的序列生成的，当新...[/quote] 你好！ [b]1、NHibernate应该是可以的；EF貌似不行 2、我觉得这种应用情况还是比较普遍的，此时你需要将由ORM根据数据库产生的Model与Domain Model区分开来。一旦Model从数据库产生，那么它就已经是Data Model，而不是Domain Model了，再在这个Data Model上去手工添加一些Domain Model的特质就显得很牵强。我觉得在这种情况下，可以走的路有2条：a、不选用领域驱动设计；b、先抛开由ORM根据数据库产生的这个Data Model不理，首先设计好Domain Model，然后使用PoEAA中的相关模式做Domain Model到Data Model的Mapping，此时，ORM将不再是ORM的角色，仅仅是一个数据访问和存储的工具 3、Oracle我不是太了解，记得是需要配合Trigger来实现的。如果是SQL Server，那么在EF做Mapping的时候，可以在EntityTypeConfiguration里使用HasDatabaseGeneratedOption方法，自动获取ID，此时如果你是使用本案例中仓储的实现，那么在仓储将实体Add到数据库之后，实体的ID就会被赋值了。另外需要注意的是，DDD里的ID的含义与数据库里主键的含义是不同的，不主张使用数据库主键作为实体的ID值 4、我觉得实体本不应该具有“保存时间”这样的属性，因为实体不可能知道自己会被如何保存，甚至是什么时候会被保存，因此这是违反DDD的做法；但如果是数据库驱动的设计，那这就没有问题。反过来，如果你真的有这样的需求，设计如下：[/b] [code=csharp] public interface IAggregateRoot { DateTime? DateSaved {get;set;} } public class Customer : IAggregateRoot { } public class MyRepository : Repository where TAggregateRoot : class, IAggregateRoot { public void Add(TAggregateRoot aggregateRoot) { aggregateRoot.DateSaved = DateTime.Now; context.RegisterAdd(aggregateRoot); } } [/code]

dax.net 2012-04-28 10:00 发表评论

Re:EntityFramework之领域驱动设计实践【后续篇】：基于EF 4.3.1 Code First的领域驱动设计实践案例

dax.net — Sat, 28 Apr 2012 01:30:00 GMT

[quote]Kain：不知道怎么处理比较复杂的权限过滤的问题？例如根据权限查看特定类型的订单？[/quote] [b]这个问题三言两语估计也讨论不清楚。请参考：[/b][url=http://www.utwente.nl/ewi/trese/graduation_projects/2008/Uithol.pdf]http://www.utwente.nl/ewi/trese/graduation_projects/2008/Uithol.pdf[/url]

dax.net 2012-04-28 09:30 发表评论

Re:【领域驱动设计】浅谈聚合的划分与设计

ibbcall — Fri, 27 Apr 2012 02:20:13 GMT

@八匹马我倒认为DDD也可以解决您遇到的问题，DDD是一种思考问题的方式。您可以把信息可以扩展这个用户需求，不先从数据库角度考虑，把他当成是一个领域问题，从领域模型中去解决这个问题，之后再考虑领域模型持久化到数据库的问题。用DDD方式开发的前期投入是比较大的，对开发、设计人员要求要高一些，设计合理的话，后期的维护量反而不大。

ibbcall 2012-04-27 10:20 发表评论

Re:领域驱动设计系列文章汇总

ibbcall — Fri, 27 Apr 2012 01:59:22 GMT

有几个DDD方面的问题请教楼主，问题如下： 1. 如果把值对象中的属性通过readonly或其他形式定义成只读的，是否无法使用EF或NHibernate等ORM工具？ 2. 现有的ORM工具更多的是考虑编码效率，是为了减少编码量，把一个映射看成是机械形式的。而现实中如果已经有一个在线运行的数据库，在此基础上构建领域模型，会有不少设计会受限于ORM工具，我们有部分持久化和反持久化工作是通过手工代码实现的，因为我认为保持最小技术因素领域模型是值得的。您怎样看这件事情？目前是否有半手工实现的ORM工具？ 3. 实体对象ID在我们系统中是通过Oracle数据库的序列生成的，当新生成一个实体对象时，其ID号在何时通过什么方式赋予比较好？ 4. 业务中会有许多需要记录操作时间的地方，这个时间在我们系统中要求是写入数据库瞬间的数据库时间，当这个操作时间同时也是一个实体属性时，怎样处理这个问题比较合适？先行谢过！

ibbcall 2012-04-27 09:59 发表评论

Re:EntityFramework之领域驱动设计实践【后续篇】：基于EF 4.3.1 Code First的领域驱动设计实践案例

Kain — Thu, 26 Apr 2012 10:42:35 GMT

不知道怎么处理比较复杂的权限过滤的问题？例如根据权限查看特定类型的订单？

Kain 2012-04-26 18:42 发表评论

Re:领域驱动设计系列文章汇总

dax.net — Thu, 26 Apr 2012 01:33:22 GMT

[quote]人面兽心：实在感谢，楼主威武，这方面的资料真少，谢谢楼主的分享[/quote] [b]呵呵，客气客气。[/b]

dax.net 2012-04-26 09:33 发表评论

Re:领域驱动设计系列文章汇总

人面兽心 — Thu, 26 Apr 2012 01:27:17 GMT

实在感谢，楼主威武，这方面的资料真少，谢谢楼主的分享

人面兽心 2012-04-26 09:27 发表评论

Re:EntityFramework之领域驱动设计实践【后续篇】：基于EF 4.3.1 Code First的领域驱动设计实践案例

dax.net — Wed, 25 Apr 2012 07:01:33 GMT

[quote]魂逆漫：楼主，我是菜鸟，ef一定要用sqlserver数据库吗？用mysql行不？[/quote] [b]要看有没有基于MySQL的EF Provider，Oracle应该是可以的。你可以上Oracle的网站下载。[/b]

dax.net 2012-04-25 15:01 发表评论

Re:EntityFramework之领域驱动设计实践【后续篇】：基于EF 4.3.1 Code First的领域驱动设计实践案例

dax.net — Wed, 25 Apr 2012 07:00:55 GMT

[quote]Danny.tian：请问楼主，你手动创建的XSD文件和使用pure poco有什么区别吗？使用XSD的考虑是什么？谢谢！！[/quote] [b]没有区别，我在这里用XSD设计DTO，就是为了能够方便地使用第三方工具图形化设计XSD，然后可以使用svcutil.exe/dconly命令行自动化代码生成。DTO跟领域模型对象是没有关系的。当然这些DTO你也可以自己用手写。[/b]

dax.net 2012-04-25 15:00 发表评论