首先声明，这不是真的就是什么Best Practice。只是看了老赵的文章里面提到了WebForm的Best Practice这个词汇后，突然有了这样的想法，把自己平常在使用WebForm开发过程当中，自己认为比较好的开发实践拿出来与大家共享，这个可能不是我一个人能完成，希望大家都能参与进来。由于平常我写博客并没有太多的耐心和持续性，三分钟热度要过了就不了了之了，所以虽然现在比较晚了（刚过0点），但为了这篇博客能够最终成型，还是决定连夜把这篇博客赶出来。
近一段时间以来，我发现博客又掀起了新的一轮讨论热潮，特别是针对WebForm和MVC的讨论。这样的讨论可以促进大家的进步，同时也可以让每个人对每种技术的了解都更加深入。不同的技术都有自己的最佳实践，比如WebForm和MVC。如果我们大家在平常的开发实践中都能遵从每一种技术基本使用原则，而不是滥用，那么我就不信不会得到最佳效果。
这里，我要讨论的是如何合理的利用DataSourceControl，来简化我们在页面的一些数据操作，代替一部分的参数处理工作，并最终取代页面的后台代码文件。这个思路，源于在asp.net Blogs的一篇文章（我目前已经找不到该文章的链接的，大概意思就是讲如果利用DataSourceControl来封装一些复杂的数据处理）和NBearDataSource的基础上提出来的，目前已经应用了一个网站项目的开发，并且自认为这是一种值推荐的WebForm开发方式。
在ASP.NET 2.0中，提出一种新的数据绑定方式，都就是使用DataSourceControl控件来查询数据，而数据控件本身只要指定DataSourceID即可以与DataSourceControl关联，而DataSourceControl本身会调用会根据不同的实现的自动进行参数的指定和查询的工作。在ASP.NET 2.0，内置提供了ObjectDataSource，SqlDataSource和AccessDataSource。可以说，我们经常使用的都会是ObjectDataSource，但是由于功能限制的原因，很多情况下都还比较复杂。这时如果仅限于使用系统提供的DataSourceControl，那它的功能基本就废了。
我对DataSouceControl的实践是将不同模块（或数据查询）统统封装成一个一个的DataSourceControl。DataSourceControl的基类可以是ObjectDataSource，也可以是直接从System.UI.DataSourceControl继承而来，在抽象方法的基础进行实现。但是建议还是要一个处理公有逻辑的DataSourceControl基类，比如如果你使用NBear解决方案，那么你可以从NBearDataSource继承而来；或者如果你使用LINQ，则可以创建一个LINQDataSource。以NBearDataSource为例来解析这样做的好处：
1)在NBearDataSource中，对数据的查询，我们只要指定实体类型，然后根据条件参数生成WhereClip，然后调用NBearDataSource.Filter方法，即可完成一个简单实体的查询。不需要调用Gateway查询接口。
2)在NBearDataSource中，在数据提交时（新增和修改）转入的数据赋值到对应的实体对象中。比如如果你使用FormView与DataSourceControl结合使用进行新增修改数据，那么FormView里提交的字段，你就不需要一个一个的去从输入控件中去获取，使用Bind双向绑定，在DataSourceControl就可以得到所有输入字段值。而NBearDataSource更是会把所有提交的字段，都给我们赋值到一个指定的实体对象中，直接就可以保存到数据库了
3)每个DataSourceControl，根据自己的功能不同，可以灵活进行修改的控制。并作为页面，与逻辑服务的桥梁。
在这样的实践中，DataSourceControl是整个数据展示的核心，也是一个桥梁。可能相当于MVC中的C吧。但是这在网站型的项目当中应用有以下一些优势：
1)它可以与任何的数据绑定控件紧密的配合，在最合适时间进行数据的查询和绑定工作，不需要用户用工干预。防止了很多情况下重得绑定的可能。
2)使用DataSourceControl，可以让后台很多为了数据绑定而写的代码，包括分页代码，统统退休。
3)使用DataSourceControl，可以方便的让某一部分数据在不同的页面进行复用，而不用提供复杂的查询条件和所需的查询接口调用。
4)DataSourceControl可以封装查询参数的传递。比如你的查询参数是从URL而来，那么你完全就可以把参数的处理交给DataSourceControl了。
5)DataSourceControl在数据提交时字段的自动映射方面非常的有优势，。
6)DataSourceControl非常灵活，如果我们的页面外观上不需要变动，只是在数据源需要进行一些修改，那么这时只需要修改DataSourceControl即可。
这样做以后，项目中可能会有很多DataSourceControl，但是同时我们可以减少的是页面后台代码，让偶尔的一些服务器代码写在aspx文件中，让页面更易于维护，不用编译就可以生效。同时如果你把DataSourceControl放在一个独立的Library中，那它的复用就更加的容易了。
同样的，这样模式也不是到处都能用的。只适用于WebForm的数据绑定控件。（对于数据绑定控件的性能我就不再多说了。老赵已经解释了非常清楚了，重复一点数据绑定控件生成HTML的性能完全没有问题，特别是它的组件化的思想非常的优秀。）
最后，给出一种最为简单的复用。比如你的项目中有很多的枚举类型，在页面上你要显示这些枚举可能会需要一些代码。这时候我们可以写一个EnumDataSource，只要在页面上给EnumDataSource指定一个枚举的类型，这时由EnumDataSource去读取枚举相关的名称，值和中文描述。对于所以有的枚举都使用EnumDataSource来绑定，不管是DropDownList还是CheckBoxList，那么你是不是觉得的非常的简单呢？
本篇的介绍就到此为止，欢迎拍砖。
作者：阿不
