例如在登陆模块中，在用户登陆成功后一般是保存用户的id呢，还是关于用户的信息都保存到session中？？？说明：为什么有这个疑问：
在不同的页面需要的用户信息不一样，比如在index.aspx页，可能有XXX恭喜登陆成功的提示信息。
而在MemberInfo.aspx页需要用户的十个属性左右。还有可能第三个页面，第四个页面需要用户用户信息，但是很多不一样。如果是登陆成功时都保存到session中，那么服务器的压力可能会比较大；如果保存用户id，那么需要用户用户信息的页面都需要取一遍数据
请问各位大侠，何以抉择？？？
最好能说说优缺点，谢谢了！！！
在不同的页面需要的用户信息不一样，比如在index.aspx页，可能有XXX恭喜登陆成功的提示信息。
而在MemberInfo.aspx页需要用户的十个属性左右。还有可能第三个页面，第四个页面需要用户用户信息，但是很多不一样。如果是登陆成功时都保存到session中，那么服务器的压力可能会比较大；如果保存用户id，那么需要用户用户信息的页面都需要取一遍数据
请问各位大侠，何以抉择？？？
最好能说说优缺点，谢谢了！！！
session可以保存少量的数据,如果网页浏览者很多,session 保存就很吃力.
Session中一般存放频繁使用、少量的数据，除了Session外，还可以存放在Application、Cookies、Cache、隐藏域hidden、临时文件、数据库、静态类或类的静态成员中。Cache有时是个较好的选择。
如并发情况等……
以前好像接触过一个叫runer的测试工具……
存实体类对象和存datatable有何区别？？？
对象使用的相对频繁，ID一般做添加，修改，保存日志使用.
系统和数据库，是2台服务器.
其实我也不知道这样好不好...
ASP Session状态存于IIS的进程中，也就是inetinfo.exe这个程序。所以当inetinfo.exe进程崩溃时，这些信息也就丢失。另外，重起或者关闭IIS服务都会造成信息的丢失。
一般在Session中存储少于100K的数据。SESSION三种模式1、InProc 存在IIS进程中 当IIS进程回收时。SESSION是一起回收的就失效了。2、StateServer 存在asp.net state server服务3、SqlServer
举个例子：aaa.aspx、bbb.aspx、ccc.aspx这三个页面都需要用到用户信息，但是三个页面需要用到的数据完全不一样，请问是在哪个页面取数据，按照你的说法，在登陆后保存id，然后跳转到指定的页面（只能是这样了，不然的话不能确定获取用户信息的代码保存写在那个页面。），如果是这样的话，那就等同于在登陆成功的时候就获取用户所有信息，然后保存到Session中。谢谢了！！！
session容易丢失，可是使用ViewState保存内容
这个跟服务器内存大小也有关系，不过硬件应该都不是问题了
Response.Cookies["dtusername"].Expires = DateTime.Now.AddMinutes(20); // 20分钟
你不知道分层吗？
你页面需要的东西是user这个对象，自然是直接向bll要的。
bll从数据库、cookie或者session取和你a.aspx、b.aspx、c.aspx完全无关啊
不过我反对cache是较好的选择.特别是对于保存用户id之类的时候...
因为cache是全局作用域的好像....
一般保存session["id"]吧....
看情况.如果user用户信息要频繁调用到的话.就把需要的都保存了.如果只是偶尔调用一次的话就有个ID就O了,需要的时候再去查询一下
比如用户的权限和角色 的生成 比较麻烦，每个页面都得要验证，不能频繁的查询数据库再生成。
都是把这些对象存到session里面的。不过确实session占资源，不知道各位有什么更好的解决方案呀。
实际上是一个hashtable!!!!理论上，如果服务器内存足够大，你放什么都可以！
通常情况下，即使是分层，只要你想bll去数据，最终还是会操作数据库
这样和每次需要用户信息都操作数据库有什么区别吗？？？
不太重要的信息考虑放到Cookies中
不是很明白！
在此讨论的是用户信息。
id、密码等，保存到session；性别、年龄等保存到cookies中吗？？？
这样好像比较别扭，如果用户删掉或者禁用cookies的话，那么开发时不管是保存用户数据，还是后面的获取数据都比较麻烦，个人认为这样的“可控性”不是很好！继续求解！谢谢了！
大數據量不實時更新的放在cache裏面比較好，全局的大量數據放application里
Session比较耗内存，并且不太稳定，所以不适合保存大量的数据，一旦访问大会明显降低性能
比如你上面的，Session中可以只保存一个id或者用户名（主键）就行了
其他信息（包括刚才的Session中的那个字段）一并放到Cookies中
要用的时候，用的Request.Cookies[(string)Session[id]]["Email"]就好了
当然你要先验证Session不然容易出错
为了防止Cookies丢失，每次用户登陆时，你可以检查Cookie是否存在，不存在就重新写一遍
（但事实上大多数时候是存在的，只是确保，实在不行你还可以拿Session去查数据库吧）
可以把信息存到cookies 密码就不用存到这个里面去了。
反正你密码只有在登录的时候用到。所以一些基本信息是可以存放到cookies中的。
这样做的话，用户密码等敏感信息肯定需要加密吧？？？
即使加密过后的文本还是可以改动的，那么请问如何判断cookies是否被篡改呢？？？
如果需要去通过查询数据库判断的话，那么，这个保存操作就没有意义了！！！继续求解！！！谢谢你！！！
Cookie中一般只存放不太重要的信息，它本身就是“不安全的”，所以密码不要放到里头了，你可以采取服务端加密解密的方式存取
Cookie中的数据通常只用来作为一个简单显示（比如CSDN上面显示的用户名，如果篡改了导致显示不正确，那与你服务器有什么关系，让客户端自己去找360去吧！禁用Cookie当然会带来不便，没有Cookie的只好每次都让用户自己再输入验证一遍了，但是这样客户端会占到多少呢？
Session是服务端的，的确要安全很多，安全就必须付出代价，太多的Session会加重服务器的负担
Cookie是存在客户端，并且是相对持久的，所以大大减轻了服务端的负担，但同时也带来了安全问题
不能光判断Cookie是否存在，而是要判断持有这个Cookie的用户是否存在
首先你没办法决定客户端必须是怎样的环境，但是服务端可以也必须严格控制哪些数据被写入到数据库中，那就是不断地加强权限验证和输入验证
嘿嘿，谢谢你再次光临！“禁用Cookie当然会带来不便，没有Cookie的只好每次都让用户自己再输入验证一遍了，但是这样客户端会占到多少呢？”
这段话好像有点跑题了？？
这段话好像在说登录的“记住密码”功能？？？哎，感觉做web就是麻烦！！！
需要考虑到各种各样的情况，导致这两种情况的“肇事者”可以分为两类，“懂技术的”和“普通用户”，并且随随便便给个提示或者不予考虑，自己还感觉很惭愧！！！
一般情况是不会的，即使是删除了，那让他重新登陆验证是理所当然的事情，谁让他删的？
所以BS客户端的事情最好不要牵扯得太多，只是利用它减缓一点系统负担而已，登陆时可以先判断
if(Request.Cookies["user"] != null && Request.Cookies["user"].HasKeys)
//应该说Cookie是存在的
else
//去查数据库，将信息写入Cookie，以便后续使用其实上面的逻辑已经大大减轻了查询次数（因为只要用户登陆过，绝大多数时候Cookie是存在的，所以else里面的查询工作频率并不高
相比Session这么个不稳定的东东来说要好很多
你向SQL传参 where user = @user and password = @originalPwd
这里比较容易被注入，不要偷懒，用SqlCommand
录入的信息的时候要客户端服务端同时验证非常必要
那是因为我们在用户整个操作期间,需要频繁的调用该用户的各种信息,比如用户的名称,所在的部门,或者用户的权限等,几乎每一个页面,都需要类似的判断.
假如仅存储用户的ID,内存倒是用得少了,但数据库可就用得多了.是牺牲内存好呢还是牺牲数据库好呢？结果当然是牺牲内存来得比较好。所以，用户的信息，当然是存储在session是最经济实惠的作法。然而，牺牲内存也不意味着无节制的乱用。
一般来说，将用户信息存储到session中，初衷意义在于部分用户的信息需要在系统中频繁使用，为了提高性能才采取此措施，所以，从这个目的出发，我们应该尽可能的只将确实需要频繁使用的信息存储到session中，而不是随便阿猫阿狗都写进去。存储的时候，当然要把对象写进去，但这个对象必须另行编写，比如，可以将需要频繁使用的数据（每表仅取若干字段而非全取），根据多个表的情况，另行建立一个对象，其中的属性分别通过多表联查的形式一次读取。这样，即保证了我们在代码中调用提升性能，又不至于因为写入了部分不怎么使用的字段浪费内存空间。再其次，事实上是可以通过简单的计算得出允许消耗的内存数量。假如我们在session中存储了用户的ID、姓名、部门ID、部门名称等信息，简单计算我看也不过100字节左右，就算存多一些，一个用户1000个字节吧，那么，我们只需要消耗1M的内存，就可以容纳1000个用户在线，只需要消耗10M的内存，就可以容纳10000万个用户的在线。以如此之少的内存消耗，就可以容纳如此之多的用户，这是一件多么具有性价比的事！需要说明的事，必须大力反对滥用session的行为。很多初学者，经常直接在页面中使用session来传递参数，这种行为是非常低级和恶劣的，没有必要的浪费，才是最大的可耻。
谢谢，费心了！！！
有同时验证客户端和服务端的吗？？？
就像微软提供的验证控件一样，只是验证控件有时候不怎么灵活，比如onmuosrover时调用Ajax验证……
减少数据库读取，应该使用统一的cache，不是session...
怎么说，存在session里面就直接可以取出来了啊？？？
和存在cache里面有什么区别么？？？谢谢！！