我已经看到这是各种代码库,并想知道这是否通常不赞成。
例如:
public class MyClass
{
public int Id;
public MyClass()
{
Id = new Database().GetIdFor(typeof(MyClass));
}
}
答案 0 :(得分:11)
答案 1 :(得分:10)
有几个原因通常不被认为是良好的设计,其中一些例如导致难以进行单元测试,并且已经提到了处理错误的难度。
我选择不这样做的主要原因是你的对象和数据访问层现在非常紧密耦合,这意味着在原始设计之外使用该对象需要大量的返工。举个例子,如果遇到一个需要使用该对象的实例而没有分配任何值来保存该类的新实例?你现在要么重载构造函数,然后确保所有其他逻辑处理这个新案例,或者继承和覆盖。
如果对象和数据访问被解耦,那么您可以创建一个实例,然后不进行水合。或者,如果您的项目使用相同的实体但使用不同的持久层,则对象可以重复使用。
说过去我在项目中采用了更简单的耦合方式:)
答案 2 :(得分:7)
这也会使编写类的单元测试变得困难,因为您将无法强制类使用db类的Mock / Stub版本。看这里: http://en.wikipedia.org/wiki/Dependency_injection
答案 3 :(得分:7)
如果您参考数据库连接,则可以使用一次性模式:
public class MyClass : IDisposable
{
private Database db;
private int? _id;
public MyClass()
{
db = new Database();
}
public int Id
{
get
{
if (_id == null) _id = db.GetIdFor(typeof(MyClass));
return _id.Value;
}
}
public void Dispose()
{
db.Close();
}
}
<强>用法:强>
using (var x = new MyClass())
{
/* ... */
} //closes DB by calling IDisposable.Dispose() when going out of "using" scope
答案 4 :(得分:4)
是的,你可以做到,但它不是最好的设计,构造函数中的错误处理并不像其他地方那样整洁。
答案 5 :(得分:1)
我能用这种方法想到的唯一问题是,数据库初始化中的任何错误都将作为构造函数的异常传播。
答案 6 :(得分:-3)
为什么有人想要使用模拟对象/存根而不是真实的东西? 您是否同意汽车制造商应使用纸板模型 对于崩溃测试?