对Stella Forum的几点看法
Stella Forum
是
notus
写的一个开源论坛，使用了
听棠
的SPL这个orm组件。我由于学习SPL的缘故，参看了论坛的源码，在项目的贴子上谈了一些自己对于orm的想法，猜想可能对orm新手可能会有点启示，转过来和大家分享。
因为我现在的项目计划需要使用SPL,所以打算从楼主的这个开源项目里面学习一下。但是在看了以后，我认为楼主的结构设计还是不错的，不过有几个地方我觉得不妥。楼主使用了SPL这个orm组件，但是我不知道楼主用这个做什么？难道只是使用它那个方便的代码生成器生成entity？或者使用entity中方便的CUID吗？或者就是为了使用orm而使用orm么？而且楼主除了使用我上面说的SPL的几种最基本的功能，没有使用任何高级的功能吧？总而言之，我认为楼主没有正确的使用orm。
我就我的理解提几个改进意见：
1
、就结构看，楼主的结构和petshop3的结构很类似，猜测可能也是对他的一种仿照吧？如果是这样，楼主可以去掉Factory模块了。就我理解，petshop3之所以设计这个模块，主要是提供可以根据web.config中不同的设置使用不同的数据库访问组件，但是SPL本身已经实现了对多种数据库的兼容，所以这是不需要的。
2
、对SPL生成的entity，由于是和数据库表的直接对应，肯定是不符合系统的业务模型的。为了改进entity，系统选择了重新编写一个Model，我不赞同。我认为可以采用两种方式，一种是组合，一种是继承。举个例子，在我写过的一个稿件管理系统中，一篇稿子（Thesis）有n个作者（Author）。对于组合，我可以新建一个ThesisModel类，以组合一个Thesis对象和一个Author数组；对于继承，我也可以新建一个ThesisModel类继承自SPL生成的ThesisEntity，然后添加Author数组等属性和其他的相应操作。
3
、对于entity的操作，我也喜欢使用一个单独的action来实现。实现的方式，和上面一样，也可以使用组合和继承，充分利用自动生成的action。这样做的一个好处就是，如果以后的数据库结构更改了，由于采用了组合或者继承，仍然可以使用自动生成的代码，轻易适应这种更改。
4
、orm的初衷就是要隔离数据对象的使用和对数据库实际的存储操作，以方便以面向对象的方式使用数据库，所以对数据库的操作最好通过orm内置访问方法进行。只有在orm组件提供的访问方式不能实现所需的操作或者性能不能满足要求的时候，才使用直接的SQl查询语句或存储过程实现。这样做的好处之一就是可以充分利用orm工具对异构数据库的支持的特性，便于移植；另一个好处就是更难出现低级错误，节省时间。这个项目使用了大量的存储过程，我没有仔细看过，不便评论，但还是建议简单的查询使用orm内置的面向对象的查询方式。