几种数据层的适用场景

 

数据层是个老话题，自从有了三层的概念，就一直被讨论。今天参加了个面试，问到了这个问题，发现这个问题虽然不难，但说的清楚透彻也需要总结一下。下面是对使用场景的总结，具体的技术是老生常谈的问题，就不过多的讨论了。

 

1、存储过程

适用场景特点：

性能要求高

业务逻辑简单

很少移植

适用场景：

例如信息类网站，小型的B2C网站，小型项目型软件系统。

原因：

    存储过程经过数据的预编译，性能比SQL提高一些，安全性也较高。但是存储过程也有其自身的局限性。可读性较差，如果业务逻辑较复杂，调试起来很不方便，维护成本也会很高。不同的数据库之间，存储过程不一定兼容。对数据库升级，会带来许多不可预知的问题。

    大部分网站符合这几个特点，网站对读的操作多，写的操作少。业务逻辑简单，选择好一个数据库，短期内不会移植。

   

2、SQL写到应用程序中的Data layer层。

适用场景特点：

   性能要求较高

业务逻辑比较复杂

经常移植

适用场景：

企业应用系统，软件公司自主研发的小型产品型软件。例如OA,CRM之类的软件。

原因：

产品型软件，需要对不同的客户实施，每个客户要求的数据库系统有可能不同，业务逻辑也有差异，能提供方便的二次开发。如果写到存储过程中，做二次开发非常不方便，而且数据库移植也很差。虽然性能方面不如存储过程，但对于并发较少的系统，损失点性能的优势来换取扩展性和移植的突破是非常值得的。

 

3、Data Mapper处理数据层。

适用场景特点：

   性能要求较高

业务逻辑复杂

经常移植

适用场景：

企业应用系统，软件公司自主研发的大型产品型软件。例如ERP系统。

原因：

稍微解释下Data Mapper。对于关系型数据库又叫ORM，是数据与对象的映射，直接使用Data Mapper，省去了开发SQL的麻烦。适用Data Mapper最主要的原因是在一个大型的软件系统中，业务逻辑复杂，使用传统的基于数据库表的思维是开发，对将来的扩展性就很差。这就引入了领域驱动的开发方式，数据处理大部分交给Data Mapper处理。对于二次开发，只关注业务逻辑，不必考虑数据库就能完成，这是最理想的状态。