数据访问层的静态方法
我在数据访问层 (DAL) 中使用了很多静态方法，例如：
public static DataTable GetClientNames()
{
return CommonDAL.GetDataTable("....");
}
但我发现一些开发人员不喜欢 DAL 中静态方法的想法。我只需要一些理由在 DAL 中使用或不使用静态方法。
谢谢托尼
I have used a lot of static methods in Data Access Layer (DAL) like:
public static DataTable GetClientNames()
{
return CommonDAL.GetDataTable("....");
}
But I found out that some developers don't like the idea of static method inside DAL. I just need some reason to use or not use static methods inside DAL.
Thanks
Tony
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
从纯粹主义者的角度来看，这违反了各种最佳实践（例如，对实现的依赖、紧密耦合、不透明依赖等）。我自己也会这么说，但最近我倾向于转向更简单的解决方案，而不是过多地关注“企业”功能和流行语。因此，如果您愿意编写这样的代码，如果这种架构允许快速开发并且可测试，并且最重要的是解决您的业务问题 - 那就很好。
From purists' point of view, this violates all kinds of best practices (like, dependency on implementation, tight coupling, opaque dependencies, etc.). I would've said this myself, but recently I tend to move towards simpler solutions without diving too much in "enterprizey" features and buzzwords. Therefore, if it's fine with you do write code like this, if this architecture allows for fast development and is testable and, most important, solves your business problem -- its's just fine.
如果我必须选择一个不使用静态方法的原因，那就是它限制了您针对代码编写单元测试的能力。例如，为 DAL 创建模拟会更加困难，因为没有实际的代码接口，只有一堆静态方法。如果/当您决定采用需要接口来支持 IoC、依赖项注入等内容的框架时，这会进一步限制您。
If I had to pick one reason not to use static methods, that would be that it limits your ability to write unit tests against your code. For example creating mocks for your DAL will be more difficult because there is not an actual interface to code against, just a bunch of static methods. This further limits you if/when you decide to adopt frameworks that require interfaces to support things like IoC, dependency injection etc.
这就是
工作单元，只是静态的，不是吗？That's
Unit of Work, just static, isn't it?