NPA——.NET Persistence API

你可曾听说过JPA。

 

有JPA那么就一定有NPA。

 

软件架构的路上一定少不了这个名词。

 

——————————————————————————————————————————————

P

Persistenc

持久化

所以它一定是基于O/RM的。

 

那么很容易理解，它封装了O/RM，

不管你使用何种O/RM，都需要对O（object）的操作，

简单来说，提取他们的接口就成了NPA。

 

每个映射的实体可能都需要类似Save,Update,Delete,Get等操作，

扩展开来有GetAll,GetBy条件，GetCount,及分页等操作。

引入NPA的好处就是可以省去这些操作的具体实现，

不管你是手动编写他们，或是使用代码生成器生产他们，都可以解放你的一切，简化你的代码生成器。

 

O/RM对开发者来说是半透明的。

为什么不是全透明的？

全透明过于理想化，还存在着以下几个问题：

1、映射，各种ORM也许都有以上提到的操作方法，但它们的映射办法绝对不会相同，从这里也可以看出NPA不需要支持多种ORM，只需要支持一种即可。

2、控制力，直接使用ORM都会带来很大的争议，性能与效率是永恒的话题，如果再过分的封装，那么势必造成开发者对自己代码控制力的不足。

 

有必要引入NPA的思想吗？

不好说，看个人。

这个世界什么都追求效率，简单说就是一个字，“快”。

互联网公司拼了命赶上线时间，快递哥也是拼了命的赶时间，快餐业也是拼了命的30秒餐到你手。

引入NPA的时间成本，与日后驾驭后的产出，值不值得，这个只能问自己。

 

如何引入NPA？

本人从纯手写SQL--》封装DBHELPER--》引入简单ORM--》精通轻量级ORM

--》轻量级ORM与传统数据访问方法结合--》去除ORM特有的配置文件

--》封装ORM的基本操作--》打造NPA专用的代码生成器

历经多年时间逐步完善。

 

不是那个NPA。

老外有个将JPA移植到.NET平台的NPA，

初看了下接口封装的不是很喜欢，

都说老外在软件方面领先国人，但也不是所有老外都能超越所有国人的。

 

那么在哪可以看到NPA

我的博文中，软件架构设计一类的，都带有些它的思想，

因为本人使用的ORM是NHibernate，你以后会看到一个版本，

这个版本你看不到NHibernate麻烦的XML配置文件，即使是代码生成器，也只是生成了很简单的代码，

简单的映射，简单的使用，“一个框架两套数据访问机制”。

 

——————————————————————————————————————————————————

不是我创造了NPA，它本来就存在，我知道它的存在，于是我找到了它而已。