服务消息、业务实体以及数据实体

 

服务消息、业务实体以及数据实体

 

名次解释

 

服务消息 － 分布式应用中各个服务之间传递的消息，以WCF为例的话就是数据契约。

业务实体 － 业务对象模型、领域模型中和业务相关的实体。

数据实体 － 完全和关系型数据库结构对应的数据实体。

 

问题

 

    今天有人在MSN上问了我一个问题引发了我的思考，问题大致如下：

最近在学习3.0的一些技术，比如WCF和LINQ，我尝试使用这些技术写一个分布式的新闻系统，系统的构架如下：

※     一个数据访问层，其中包含了一个数据实体（自动生成的）。数据访问层使用Linq To SQL进行数据访问操作，并且把数据从数据实体转化为领域模型中的业务实体。

※     一个业务逻辑层，以领域模型为核心。业务逻辑层使用Linq To Object再把业务实体转化为WCF的数据契约。

这样，整个项目中就有了三个实体：

※     数据实体 － 和数据库对应的实体：新闻类、评论类；

※     业务实体 － 有层次及依赖关系的一些类：新闻基类、普通新闻类和重要新闻类分别继承新闻基类，新闻基类持有评论类的聚合；

※     服务消息 － 供WCF作为消息的实体：还是新闻类和评论类，和数据实体相比少了一些不必要的属性。

等新闻系统做好之后我就非常郁闷，我不知道我干了一些什么：

※     从数据实体到业务实体之间的转换非常麻烦，而业务实体又不适合作为数据契约。业务实体的意义何在？

※     几次转换再加上WCF（基于HTTP），整个系统的性能奇差，WCF以及Linq先进的构架反而不如以前ADO.NET加上单物理服务器的构架？

 

讨论

 

    这位朋友的疑惑涉及到很多已经讨论了很久的话题：

※     ORM的意义？

※     分布式（或者说面向服务）的意义？

※     领域模型的意义？

我认为：

※     很多时候，我们的思考都反了，不是说要OO才ORM，而是我们在建立了领域模型之后需要做持久化的工作，完善的ORM框架能帮我们做这个转换、存储的工作，减少了代码量。

※     Linq To SQL主要还是针对数据库模型（数据实体），并不能处理非常复杂的领域模型的持久化，可以关注ADOEF。

※     很多时候我们觉得一个概念没有什么意义，或者说带来的反面效果比正面效果还大的时候往往是因为拿大炮打蚊子了。领域模型、SO、OO都是由于当前的理念满足不了大型项目的要求而产生的，不是所有的项目都适合这些概念的。

※     有的时候看问题站在一个比较高的角度来看更客观。比如从一个操作来看待性能问题不太客观，应该从整个项目乃至整个系统（无数服务器）的角度来看。

 

请大家讨论…………

（由于大部分内容直接从MSN的对话中复制过来，所以比较乱，如果dudu觉得不合适马上移走）