<p>用Class Library创建C# DAL需封装连接逻辑、用using确保资源释放、参数化查询防注入、抽象接口支持测试、配置外置且安全、避免业务逻辑和DataTable返回。</p>
直接用 Visual Studio 创建 C# 数据访问层（DAL），核心不是“建个类库就完事”，而是要让这层真正能安全、可维护地和数据库通信。不封装连接逻辑、不处理异常、不分离 SQL 与业务，建出来只是个空壳。
用 Class Library 项目承载 DAL，但别裸写 SqlConnection
新建项目时选 Class Library (.NET Framework) 或 Class Library (.NET Standard)（取决于目标框架），命名如 DAL。关键在后续实现：
- 不要在每个方法里 new
SqlConnection+SqlCommand+ 手动 Open/Close/Dispose —— 容易漏释放、难测、耦合死 - 优先用
using语句块包裹SqlConnection和SqlCommand，确保资源及时释放 - SQL 字符串别拼接，一律用参数化查询，比如
WHERE Username = @username，对应cmd.Parameters.AddWithValue("@username", username) - 如果用的是 .NET Core/.NET 5+，推荐用
Microsoft.Data.SqlClient包，而非已废弃的System.Data.SqlClient
避免把 DAL 写成“SQL 脚本集合”
常见错误是每个数据操作都单独写一个方法，比如 GetUserById()、GetUsersByRole()、UpdateUserEmail()，最后类膨胀到 200+ 方法，且大量重复逻辑。
- 提取共用的执行模板：比如统一处理连接打开、超时、事务开启、异常映射（把
SqlException转为自定义DataAccessException） - 对简单 CRUD，可封装通用方法，如
T ExecuteScalar<t>(string sql, params SqlParameter[] ps)</t>，但别强求“全通用”——复杂查询仍需独立方法 - 别在 DAL 里做业务判断（如“密码长度校验”），那是 BLL 的事；也别返回
DataTable或DataSet给上层——用 POCO（如User类）更可控
连接字符串别硬编码，也别塞进 App.config / Web.config 就算完
Visual Studio 生成的配置文件确实能存 connectionStrings，但实际部署时它常失效：
- 开发机连的是
.\SQLEXPRESS，生产连的是sql-prod.company.local—— 配置必须可外部替换 - .NET Core / .NET 5+ 项目默认没
App.config，得用appsettings.json+IConfiguration注入 - 哪怕还在用 .NET Framework，也要通过
ConfigurationManager.ConnectionStrings["MyDb"].ConnectionString读取，而不是写死字符串 - 敏感信息（如集成认证凭据）别明文放配置里；考虑用 Windows 身份验证，或部署时用 Azure Key Vault / 环境变量注入
DAL 层测试困难？先从可替换依赖开始
很多人写完 DAL 就卡在“没法单元测试”，根本原因是直接依赖了具体数据库连接。解决思路很实在：
- 把数据操作抽象成接口，例如
IUserRepository，定义Task<user> GetByIdAsync(int id)</user>等方法 - DAL 项目中实现该接口（如
SqlUserRepository），构造函数接收IConfiguration或连接字符串 - 上层（BLL）只引用接口，不引用具体实现 —— 这样测试时可用
Mock<iuserrepository></iuserrepository>替换真实数据库调用 - 别一上来就搞 Dapper / EF Core —— 它们本身已是封装层；手写 DAL 的价值在于理解连接生命周期、事务边界和错误传播路径
真正难的不是创建项目或写第一个 SELECT，而是让 DAL 在连接中断、超时、死锁、字段变更时依然行为可预期、错误可捕获、日志可追溯。每加一个 try/catch，要想清楚它吞掉的是什么；每写一行 new SqlCommand，要确认它是否真需要独立生命周期。
