在业务服务中打开sql连接
您是否认为我的业务服务类打开 SqlConnection 是紧密耦合的?
实际上业务服务不应该知道具体的数据提供者?!
公共类UnitService:
public void DeleteUnit(Unit unit)
{
using (SqlConnection con = new SqlConnection());
using (TransactionScope trans = new TransactionScope())
{
con.Open();
_unitDataProvider.Delete(unit,con);
_employeeDataProvider.UpdateEmployees(con);
trans.Complete();
}
}
Do you see it as tight coupling that my business service class opens a SqlConnection ?
Actually a business service should not be aware of the concrete dataprovider?!
public class UnitService:
public void DeleteUnit(Unit unit)
{
using (SqlConnection con = new SqlConnection());
using (TransactionScope trans = new TransactionScope())
{
con.Open();
_unitDataProvider.Delete(unit,con);
_employeeDataProvider.UpdateEmployees(con);
trans.Complete();
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
你的问题很容易受到意见的影响......
我喜欢抽象代码并尽可能地解耦。一如既往,问题是时间和要求的问题。
对于不需要在业务层内进行大量单元测试的小型简单项目,您的耦合虽然不一定遵循最佳实践,但可能正是客户/最终用户所需要的,并且可能允许您更及时地提供软件。
对于更大/更复杂/等项目,最好抽象持久层。
对于每一行代码都遵循最佳实践、最佳设计模式和最佳编码原则是根本不可行的> 你写的。我找到了此类书籍的作者 经常提到这些模式可能超出需求,应该在需要时简单地用作工具。
希望有帮助吗?
Your qustion is very subject to opinion...
I love to abstract code and uncouple everywhere possible. The question, as always, is that of time and requirements.
For a small simple project that does not require extensive Unit Testing within the Business Tier, your coupling although does not necessarily follow best practice may be exactly what the customer/end-user requires, and may allow you to provide the software in a more timely fashion.
For a larger/more complex/etc project it may be best to abstract the persistance layer.
It is simply not feasible to follow best practices, best design patterns, and best coding principles for every line of code you write. I've found the authors of such books quite often mention the patterns as potentially surplus to requirements and should simply be used as a tool, when needed.
Hope that helps?
是的。如果您需要进行一些计算来完成该工作,则可以在到达表示层之前在业务层中进行。
我想建议的另一件事是在 SQLConnection 类的情况下对 IDisposable 对象使用“Using”语句,
我的意思是它应该如下所示。
Yes. If you have some calculation to do that job you can do in Business layer before reaching to presentation layer.
One more thing I would like to suggest is to use "Using" statements for the IDisposable Objects in case of
SQLConnection class
I meant It should be like below.