扩展方法与充血模型

不是米人，是兄弟你海阔天阔，其他兄弟还要找找轨迹~

第一层Ext:为Domain Object Ext出CURD+F的方法。

第二层Ext:为Domain Object Ext出业务逻辑方法--->依赖于第一层Ext。

在Servce层，只引用第二层Ext的namespace，因此在Service Domain Object将见业务逻辑，不见CURD，这样就干净漂亮了。

这个问题嘛！你要嘛就上aspectj，如果觉的太重了，就分开啦。
我们的做法就是把dao和model完全分离，如果的确有混合，就在service中完成。
涉及到model关联关系操作的，全部在model中做，通过root对象的引用游走访问关联对象，这里牺牲一些性能。

单就目前你提供的ext方式，看不出能带来啥好处，或者说不比其它方式省力；
在团队执行时还面临理解问题，有可能导致更不好的效果。
当然如果你能更好说明这样的方式，或者在javaeye这里有更好的讨论结果，那么在团队推行时我想才能有好的效果。

再看看，ms简化的很有限，当然能机器生成那部分代码就爽了

你的模型还是题目上“充血模型”么？？我不是要给我的团队用，我只是做一个Research而已。

扩展方法的好处比AspectJ好多了。打个比方：一个SNS系统，用户注册的时候，需要User.Regiser(),但注册之后，该用户还需要这个方法么？在用户时候的时候，在不同的Context添加各种业务逻辑。

例如在加入好友的时候，User.Regiser()可以剥离掉，而添加User.AddFriend(User u).

对于扩展方法，唯一要做的，就是引用正确的namespace!

看你怎么理解充血模型，我承认我理解的充血模型和javaeye这边普遍认识不同，
model只要不是简单get和set，包括关联，多态，以及聚合对象，拥有不超过本对象属性范围外的计算逻辑，不包括dao（数据库信息）的，就是充血模型，

俺指的就是robbin总结的充血模型。 而且偶利用两层扩展之后的充血模型，更加干净。

另外：

随着Context的不同，更换对象的操作方法，会更方便软件开发。

貌似你只能在.net下这么搞了，java下目前没有这样的技术啊！

ms有个同志也在建议Java多个Extension Method的attribute。。。

在Java里面可以用mixin，可在用户注册模块，使得User这个Class拥有某个mixin的register方法

难得你发技术文章，竟然也发在海天版块，呵呵