对于关系数据库操作方法，有很多框架。例如ADO.NET，或者Linq to SQL，或者你也可以自己封装一组叫做SqlHelper的东西作为简单工具，这些都是DAL的部分。如果说“必须围绕每一个业务实体对象搞什么DAL编程”，那已经是超过了三层的范畴，是搞更多层次的封装，而而且硬要在业务改变时将工作量扩展到多层里、平添了高耦合性。我们不会去说早期的PetShop的代码“不是三层”，它繁琐的封装当然可以说是“很多层”的，但是关键是：你对BLL层设计好了吗？如果设计好了，你的架构就是三层的。即使你在BLL中直接调用ADO.NET，又怎么能说不是三层的呢？所谓BLL层，就是一种系统服务或者叫做系统API，就是给多款前端系统能够提供统一接口、统一文档、统一行为、统一性能、统一运营服务的一种机制。在设计一个前端系统时，在前端还没有确定下来原型时，功能服务结构已经可以确定下来。这就好像“中移动”首先铺设了网络，提供了服务，才可能带动其它公司每年上千亿的创新投入，如果中移动就是搞什么数据库的公司，而不是把重点放在电信级提供服务上，它就是幼稚的。同样地，整天就是在DAL哪里去封装什么实体，而轻视了BLL的设计开发，就是幼稚的所谓“三层”。这样即使你对DAL层面层层封装，搞出了比那个用于演示的PetShop还臭味的DAL代码，你的系统对前端开发的帮助仍然是最低级的，你的BLL仍然是一个摆设。三层开发的好处根本体现不出来，“为了三层而三层”的写法反而阻碍了业务逻辑的千变万化的扩展和重构。
http://topic.csdn.net/u/20120502/14/e6c5be79-767d-45a3-829c-3612a27b13d8.html
System.Web.HttpContext.Current.Response.Write("<script>alert('用户名或密码错误')</script>");这种写法我觉得应该抽象出一个Message类来管理这种信息，或者说在某一个操作完成之后直接返回用户的操作结果，你这里写的DAL层可以用一个SqlHelper里做，也就是一个通用类
我那样写是不是有什么不妥之处？
是我理解错了？
没有什么妥与不妥的，不值得纠结在这个层次。因为你的BLL设计根本没有什么东西，我们不值得去纠结于DAL要不要额外再模仿BLL再写一个Select方法这个问题。
因为我听说那个sql命令都是在dal层生成的。
这句你说对了。所谓分层的目的，是为了降低耦合度，降低维护成本，提高复用。
比如DAL层，客户要求换一种数据库，或者开发其他的网站的时候，这个DAL层是不是可直接使用，而不需要修改任何代码，或者尽可能少的修改代码。这里网上有很多DbHelper、SqlHelper等数据访问类你可以看看。
dal层的那些类我有很多，换数据库的话换个类，换个连接字符串就够了。
关键是我不明白sql语句怎么在dal层拼接
我也是个只会写asp.net的程序员，其实现在不一定就是三层结构。很多程序已经是3+N的模型了大体的三层划分我个人理解为：
用户交互层：包括SOA给用户的调用，asp.net界面的展示，winform窗体。其实这里面细分还可以划分的，比如控制界面的代码，界面逻辑验证的代码，跟后台交互的接口。
业务逻辑层：主要处理系统业务逻辑，包括对外提供的调用接口，具体逻辑的实现模块，跟数据库交互的对接
数据访问层：对外公开的调用接口，可以考虑用类似facade的东东。还可以给sp的调用，sql语句的调用再细分，实体转换，数据缓存等等
但是很多时候我们有一些公用的功能，那么这些可能在多个系统中都是适用的，这些总不能每次都写一遍吧？
基础框架层：业务实体，公用操作类库，比如微软的企业库，系统中发送邮件，socket通信等等。具体的系统根据系统复杂度来划分。不一定就用三层，简单的可能一个页面写代码搞定，复杂的可能要细化成很多子功能模块，每个功能模块又有好多操作。设计大体通用，但是也要针对不同的系统作对应的调整。
还有dal层，如果sql命令在dal层生成的，如果一换数据库，那么dal层不是要重新编辑那些生成数据库命令的代码吗？