第一个疑问是，如果采用ORM，那么是否还需要存储过程？
存储过程的用处不仅仅是效率的提升，更重要的应该是提升了数据库对于系统中数据访问层的清晰度，数据库提供给数据访问层的，不再是一个通用的可以执行SQL语句的入口，而是更像接口函数一样的存储过程。
但是，ORM的出现，使得数据访问层在系统中的作用大大降低，由于ORM可以自动对Entity对象与数据库中的Table进行字段与属性的映射，所以我们实际可能已经不需要一个专用的、庞大的数据访问层。存储过程的作用也就变得模糊起来。
想想ORM诞生的一个原始动力，使我们可以在不需要了解低层数据库的基础上，就可以直接利用它，而不需要再去了解SQL这些数据库的东东。（Java环境中著名的Hiberate的意思就是冬眠，让数据库和SQL语句冬眠。）而再去写一个个的存储过程，反而违反了ORM的初衷。
OK，于是再引出第二个问题。如果我们在系统中全面采用ORM访问数据库（在.Net Framework 1.2中，这叫Accessing data with ObjectSpaces替代Accessing data with Ado.net），是不是降低了我们系统的灵活性了呢？
在实际的系统中，每个数据层决不仅仅就只是那统一的几个方法（返回所有数据、根据ID返回数据，根据Parent的ID返回Child数据，根据ID更新数据....等等...），为了让它工作得更好，我们总会根据具体的情况增加一些必要的方法（根据××返回记录行数...）或更特殊的方法。在这样的场合，ORM显得很笨拙，要实现同样的效果，需要费更多的周折。
不知大家怎么看待这个问题，有何看法和见解？哇，过十点半了，闪人，回家乐......