我对NP框架未来发展的一些设想

超、凢脫俗 2021-12-10 14:41 542阅读 0赞

以下是我对未来的np框架的一些设想。

在此我再次很庸俗的将未来的np分了三层。

这三层仍旧可以称为：表现层，事务层，数据层。

表现层，仍然是我们目前正在使用的DevExpress来实现。准确的说是以目前的np框架扩展开来作为最终的表现层实现。  
以现在的np为基础，做一定修改适应可能会发生的新环境。

数据层，会使用ORM，具体是使用轻量级的Linq to Sql还是功能强大的Data Entity Framework还需要实践的检验。

至于事务层，我一下子也说不清他是什么，准确的说它应该是包含一系列系统对象的，使用设计模式构架，完全以面向对象的概念来实现的一层。具体实现和具体结构应该与项目有关。

关于数据库设计，我觉得应该在目前的基础上做到以下几点：  
1.设计初衷基于对象，数据库应该是存储相应对象所需数据的存储容器。  
2.老生长谈的唯一编码准确的说应该是主键不可视，不作为客户可见的编码来使用。  
3.设计中应包含约束和各表关系，并且在数据库中已经全部相互关联。  
4.在各表中引入时间戳的概念，即加入一个**timestamp**列。

再次补充一下时间戳列**timestamp**的概念：

timestamp:**timestamp** 这种数据类型表现自动生成的二进制数，确保这些数在数据库中是唯一的。**timestamp** 一般用作给表行加版本戳的机制。存储大小为 8 字节。

说明:一个表只能有一个 **timestamp** 列。每次插入或更新包含 **timestamp** 列的行时，**timestamp** 列中的值均会更新。这一属性使 **timestamp** 列不适合作为键使用，尤其是不能作为主键使用。对行的任何更新都会更改 **timestamp** 值，从而更改键值。如果该列属于主键，那么旧的键值将无效，进而引用该旧值的外键也将不再有效。如果该表在动态游标中引用，则所有更新均会更改游标中行的位置。如果该列属于索引键，则对数据行的所有更新还将导致索引更新

备注:我们知道数字类型有个“标识”属性，设置好“标识种子”、“标识递增量”，每增加一条记录时，这个字段的值就会在最近的一个标识值基础上自动增加，这样我们可以知道哪些记录是先添加的，哪些记录是后添加的，但是我们无法知道哪些记录修改过。**timestamp**这个类型的字段呢，每增加一条记录时，它会在最近的一个时间戳基础上自动增加，当修改某条记录时，它也会在最近的一个时间戳基础上自动增加，所以我们就知道哪些记录修改过了

在使用的时候,只要拿读取出来的时间戳和表中的时间戳对比一下,如果相同,那就证明这条记录在你读取之后没有人修改过,如果不相同则证明在你读取之后有人修改过

引入时间戳的概念还是老样子，为了控制并发冲突，这和我们现在在Session中保存相应的DataSet的原因一直。  
不同的是DataSet在保存过程中是使用全匹配来实现检查并发更新冲突的。而时间戳这是比较相应行的时间戳列来实现。  
这样做的原因是为了使数据不需要在服务器端保存相应数据集的情况下仍然能很好的控制保存并发控制的问题。能避免长时间不操作后，由客户端回发数据搜寻到数据库中相应行的数据在保存时能做到数据一致性、安全性的检验。

而数据库中的关系和主键能够被我们使用的ORM识别，形成相互关系良好的ORM类，更方便我们操作数据库。  
由sql语句直接获取数据生成DataSet的方法仍将被保存下来，但是他们的作用将发生很大的改变，主要用来进行复杂语句的报表查询。

甚或我们仍然使用DataSet做数据保存，但不再将它缓存在Session中。

我个人觉得将DataSet从Session中解放出来，减少主服务器的内存占用，将是对NP框架性能的一次巨大提升。

最后，讲下我对未来的事务层的期待和想法。  
首先，在这里的事务层已经不是原来的三层的事务层的概念了。它相当于我怕之前提出来的bol层的一个变形。即事务对象层。  
这里包含的不是事务逻辑，而是事务对象。对象间做到相互松耦合，高内聚。尽量限制对象对多张数据表的依赖，以便能将数据结构修改所带来的变化带到最小。  
然后，事务逻辑的实现应该尽量使用接口和抽象类，提高系统的可扩展性和抗变化能力。  
基于时间和经验的原因这层我还没有机会试验和思考其具体的构架思路和实现模式。且这层更多的还是与数据结构与需求设计相关。  
最关键的说白了还是两点，抽象共同点，封装变化点。最需要的还是预估和归纳的能力。

以上，是我对我们目前np框架未来的一些设想和浅见。也算是一个阶段编程思想的总结全当记录在此，做一个备忘录吧。。。

转载于:https://www.cnblogs.com/reinhard1203/archive/2009/03/31/1426561.html