无DI场景下Web Forms搭配EF的DbContext使用与释放咨询

1. 是否必须使用using语句释放服务实例与DbContext？ #

不是语法层面的强制要求，但必须保证所有实现了IDisposable的资源被确定性释放，using是实现这个目标最简洁、最不容易出错的写法。
using本质是try/finally的语法糖，会在代码块退出（哪怕中途抛异常）时自动调用对象的Dispose()方法。DbContext内部持有数据库连接这类非托管资源，如果不主动及时释放，而是等GC不定时回收，高并发场景下很容易把数据库连接池占满，引发线上故障。
如果你不想用using，也可以自己手写try/finally块，在finally里手动调用Dispose()，只是写法更冗余，很容易漏写。
这里要额外提一句：你当前的UserService存在明显逻辑错误——GetUserByName方法完全没用到构造函数传入的_context，反而在方法内部又new了一个全新的DomainAppContext套了using，这直接破坏了你后续要做的上下文共享逻辑。

2. 当前代码能否实现单请求共用一个DbContext？ #

完全不能，当前逻辑存在多处缺陷：

• 最核心的问题就是上面提到的UserService.GetUserByName自行新建了DbContext实例，根本没用到页面传入的共享上下文，实际查询用户用的是独立的上下文，和后续查任务用的上下文不是同一个。
• 资源释放逻辑混乱：你把页面级创建的_appContext传给两个服务，而两个服务的Dispose方法都会主动释放传入的上下文，等于同一个DbContext会被连续释放多次（TaskItemService释放一次，外层UserService退出时又释放一次）。虽然多次调用Dispose一般不会触发异常，但这完全不符合资源释放的设计原则——谁创建资源，谁负责释放，传入的资源不应该由接收方销毁。
• 你在页面里创建的_appContext本身没有被using包裹，也没有绑定页面的释放逻辑，如果中间代码因为Response.Redirect（这个方法默认会抛出ThreadAbortException）或者其他异常跳出，很可能出现上下文泄漏。

3. 无DI场景下的更优实现方案 #

针对Web Forms + EF的无DI三层架构，最稳妥的实现是把DbContext的生命周期和Http请求绑定，完全不用在页面层嵌套多层using，就能自动实现单请求上下文共享、自动安全释放：

1. 首先修正所有服务类的逻辑：
   • 服务类的所有数据库操作，全程只用构造函数传入的DbContext，绝对不要在服务方法内部自行new上下文实例。
   • 删掉服务类里释放DbContext的逻辑——因为上下文是请求级创建的共享实例，不是服务自己创建的，服务无权销毁它，避免出现多次释放的问题。
2. 利用Web Forms的请求管道管理DbContext生命周期：
   • 用HttpContext.Current.Items作为当前请求的DbContext存储容器，这个字典的生命周期和单个Http请求完全一致，请求结束会自动被回收。
   • 写一个统一的获取当前请求DbContext的静态方法，逻辑是：先判断HttpContext.Current.Items里有没有存上下文实例，有就直接返回，没有就new一个存进去再返回，保证整个请求拿到的都是同一个实例。
   • 在Global.asax里添加Application_EndRequest事件处理方法，在这个方法里统一从HttpContext.Current.Items取出DbContext，判断不为空就调用Dispose()，不管请求中途有没有抛异常、有没有跳转，这个事件都会执行，100%不会漏释放资源。
3. 页面层的使用逻辑会变得非常简洁：需要用哪个服务，直接new服务实例，把通过统一方法拿到的请求级DbContext传进去就行，不用关心上下文什么时候释放，也不用嵌套多层using。

这种写法完全不需要依赖注入容器，纯手写就能实现单请求上下文共享，资源释放逻辑统一收敛在请求管道里，不会散落在各个页面、服务里出bug。另外要注意：单请求共用一个DbContext是EF的官方推荐实践，DbContext本身是轻量级对象，共享上下文既能保证实体状态一致（避免多上下文下实体无法跨操作附加的问题），也能复用EF的一级缓存提升查询性能。

内容的提问来源于stack exchange，提问作者mangood