asp.net优化探讨系列（1）
开篇，直入主题，先讲分层！
分层的好处不必说大家都很了，通常我们会根据需要将程序分为表现层（网站，winform等），业务逻辑层，数据访问层，为了灵活，我们还可能加上接口层或者说契约层等。
上图的的第一个项目程序是Winform，最后一个是asp.net Web application ，而业务逻辑层和数据访问层等对于这两个表现层是可以共用的，这样就看到了分层的一个好处！很直观吧，比如要将你的Web项目迁移到Winform上，那么逻辑层和数据访问层可以直接使用而不必做多大的改动！如果我们的程序要支持分布式的话，那么层之间的修改不会对彼此产生多大的影响！
ok,就此打住！分层思想的好处已经够根深蒂固了！
好了，上面的图显示了一种物理的分层，优点是结构很清晰，然而，不可否认会有一定的性能损失，虽然对于可维护性的提高可以忽略，但是对于没那么复杂的项目，分层开发还是值得考虑的，当程序被访问的时候，需要所有程序集共同协作，这样服务器要运行的东西显然会多了那么一点点，为了达到优化的效果，我们可以把这些代码和显示层放在一起，可以建立不同文件夹来区分,这样是否会觉得好点呢！如果程序支持分布式，要调用WebServices或remoting，这样做得话，性能应该会提升不少。
再说说DataSet，不知道大家的数据访问层返回数据类型是什么，DataSet是很方便，不过它是支持断开式连接，所以它会存在与内存中，就像一个在内存中的数据库一样！如果访问量大，服务器的性能就不是很好了！它的便利性也就没什么优势了！而且DataSet里面包含了DataTable对象，DataTable里面又包含了DataRow对象，真是不少!如果我们用强类型的实体，返回，采用实现集合接口的泛型集合代替，是不是感觉清爽了不少呢！比如说List<Entity>效果完全一样，也可直接绑定到数据列表控件上！而且性能也肯定比DataSet好！
最后再聊聊ViewState，外号性能杀手的它还真是令人伤脑筋，但是少了它，好像很多控件的功能都发挥不出来了，但是用了又觉得网站的性能降低了不少，前阵子的MVC热中，这个东西好像也牵涉其中，呵呵，还是那句，适当的时候再用吧！
好了，今天就到这里，继续学习！优化这个话题是比较广的，希望借此能有个机会讨论！随笔中或许有一些不当的地方，如有不对，还请指出，帮助大家一起进步！欢迎回帖啊！
分层的好处不必说大家都很了，通常我们会根据需要将程序分为表现层（网站，winform等），业务逻辑层，数据访问层，为了灵活，我们还可能加上接口层或者说契约层等。
上图的的第一个项目程序是Winform，最后一个是asp.net Web application ，而业务逻辑层和数据访问层等对于这两个表现层是可以共用的，这样就看到了分层的一个好处！很直观吧，比如要将你的Web项目迁移到Winform上，那么逻辑层和数据访问层可以直接使用而不必做多大的改动！如果我们的程序要支持分布式的话，那么层之间的修改不会对彼此产生多大的影响！
ok,就此打住！分层思想的好处已经够根深蒂固了！
好了，上面的图显示了一种物理的分层，优点是结构很清晰，然而，不可否认会有一定的性能损失，虽然对于可维护性的提高可以忽略，但是对于没那么复杂的项目，分层开发还是值得考虑的，当程序被访问的时候，需要所有程序集共同协作，这样服务器要运行的东西显然会多了那么一点点，为了达到优化的效果，我们可以把这些代码和显示层放在一起，可以建立不同文件夹来区分,这样是否会觉得好点呢！如果程序支持分布式，要调用WebServices或remoting，这样做得话，性能应该会提升不少。
再说说DataSet，不知道大家的数据访问层返回数据类型是什么，DataSet是很方便，不过它是支持断开式连接，所以它会存在与内存中，就像一个在内存中的数据库一样！如果访问量大，服务器的性能就不是很好了！它的便利性也就没什么优势了！而且DataSet里面包含了DataTable对象，DataTable里面又包含了DataRow对象，真是不少!如果我们用强类型的实体，返回，采用实现集合接口的泛型集合代替，是不是感觉清爽了不少呢！比如说List<Entity>效果完全一样，也可直接绑定到数据列表控件上！而且性能也肯定比DataSet好！
最后再聊聊ViewState，外号性能杀手的它还真是令人伤脑筋，但是少了它，好像很多控件的功能都发挥不出来了，但是用了又觉得网站的性能降低了不少，前阵子的MVC热中，这个东西好像也牵涉其中，呵呵，还是那句，适当的时候再用吧！
好了，今天就到这里，继续学习！优化这个话题是比较广的，希望借此能有个机会讨论！随笔中或许有一些不当的地方，如有不对，还请指出，帮助大家一起进步！欢迎回帖啊！
