[讨论]实际case中，有两种设计方案（附图和解说），请大家来...

我就是指你如果用第一种直接写ＳＱＬ的会很痛苦。在方法里直接用if case来判断ＤＢ类型？还是一个实体类对象一个ＤＢ类型，还是把实体类做成一个接口？无论怎么样，你都会痛苦。所以这时将方法拿出去就。。。。。：）

不妨看看这篇
http://dev.csdn.net/article/27/27495.shtm

刚一看楼主的A案例，想，一个比较简单的问题怎么可能有这么复杂的对象表示关系呢?
     再认真仔细看了一下，楼主有些滥用Composition了，许多对象关系明显地表达错误，同时在概念上没有理清，从而导致了混乱有些夸张的类图出现。
    比如说，1.一个目录可以包含子目录，但是它会是强制关系么?(你应该用聚合而不是合成，合成的意思是子对象是不能单独存在的) ； 2. 你的YPDictionary是什么？（接口或者类）从你的目的和要求来看，你所描述的应该是实体关系，而不是结构模型，将结构模型与实体关系模型描述在一起，自然就混乱了。3.CardUser是什么类？代表什么概念实体？怎么可能企业还继承了它呢？4.在产品和企业的关系同样犯了同1一样的同一个错误，难道不同的企业不能生产相同的产品么？产品就强制约束于企业么？5.产品怎么可能引用广告？应该是广告引用产品的（也就是说一个广告必定包含产品的信息，而产品是不可能去包含广告的信息的）最后也就是YPDictionary和YPEntry,其实说白了也就是Dictionary和Entry的区别，以及YP与没有YP前缀的区别，这些都让人非常的晦涩。
    做类图，建立概念模型，是要让人从复杂的现实表示与业务逻辑中抽象出来，以一种清晰的方式表现概念（对象或实体）间的关系。楼主在这点上还是有所欠缺

user.login(site);

我觉得这个感觉好。嘻嘻，不知道现在的领域对象是不是要把数据和操作放在一个类里。

但是 user.find(id) 感觉就不好了。同上所述，find的时候还要先new，不爽啦。但是做成静态呢？
user = User.find(id) ;这样如何？

噢噢，还要自己多思考。。。思考去了。。

"凤舞凰扬"，呵呵，其实观点a是公司其他人的设计，技术总监支持这个设计。我也觉得有些累赘，关于产品，广告和企业的依赖关系，我的观点也和你是一样的。方案b是我的设计，结果招来公司一帮人的反对。我是倾向使用抽象的。我发这个帖子，也是为了证实一下，自己的观点究竟是正确的还是错误的，现在看来，我有必要坚持自己的观点。
多谢大家的指点，今天太累了，先睡觉：）

哈哈，原来如此。
   楼上，相信自己的，不过也要从其他人那里汲取精华。
   如果他的权威比你大，那么你保留意见，毕竟工作还是要听从上级安排的（这是无奈确又现实的）

复杂的设计很多情况都不是一个好的设计, 而且复杂和混乱往往是同胞兄弟.
设计应该是简单的,清析的, 特别是数据模型设计的时候,更应该小心,保持简单清析和小粒度, 不然你开发的后期会很惨的.

"技术总监支持这个设计", 不是理由, 做为团队的一员你应该学会说服你的技术总监.

so cool,i like it,the same

我跳槽了，呵呵，感觉在这个团队里发挥不出我的作用，跳槽后薪水翻了一倍多，也有了一个较好的技术环境。
oop确实是一个博大精深的学问，对于毕业刚刚一年的我来说，有很多疑惑和一知半解的地方，但我深深地喜欢oop，我也喜欢抽象的思维方式，虽然新的工作不再搞java了，但开发的思想是相通的，我将继续严格彻底的贯彻oop思想，把oop道路坚定不移地走下去^_^

偶然看到，随便说说，这个正是需要应用接口的场合。（怎么面向接口编程的老兄们都不见了？）
定义一个接口叫Node,定义一个集合叫NodeCollection,
Node有Value和Text等属性，还有一个属性是个NodeCollection类型的集合。
NodeCollection集合执行添加方法的时候，可以Raise一个NodeAdded事件。
所有添加到NodeCollection的东东都要实现Node接口，NodeCollection只接受实现Node的类。
至于如何存储，那是另外一个问题。这个办法应该是实现起来最简单的了。