在 Dao 类中使用静态方法还是非静态方法?
您好,我以这种方式为某些数据库操作生成 Dao 类,
使 Dao 类的方法为静态或非静态更好?
使用下面的示例 dao 类,如果多个客户端同时使用 AddSampleItem 方法?这可能会导致什么结果?
public class SampleDao
{
static DataAcessor dataAcessor
public static void AddSampleItem(object[] params)
{
dataAcessor =new DataAcessor();
//generate query here
string query="..."
dataAcessor.ExecuteQery(query);
dataAcessor.Close();
}
public static void UpdateSampleItem(object[] params)
{
dataAcessor =new DataAcessor();
//generate query here
string query="..."
dataAcessor.ExecuteQery(query);
dataAcessor.Close();
}
}
Hi I generate Dao classes for some DB operations
in this manner making methods of Dao class as static or none static is better?
Using sample dao class below ,İf more than one client got to use the AddSampleItem method in same time?how this may result?
public class SampleDao
{
static DataAcessor dataAcessor
public static void AddSampleItem(object[] params)
{
dataAcessor =new DataAcessor();
//generate query here
string query="..."
dataAcessor.ExecuteQery(query);
dataAcessor.Close();
}
public static void UpdateSampleItem(object[] params)
{
dataAcessor =new DataAcessor();
//generate query here
string query="..."
dataAcessor.ExecuteQery(query);
dataAcessor.Close();
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
这会导致一场大混乱。如果您从不同的线程同时添加 2 个项目,那么您肯定会得到非常奇怪的结果,如果一个线程在另一个线程完成之前关闭
DataAcessor
,甚至会出现错误。我将使用本地 DataAcessor 或创建一个新的 DataAcessor 并在所有方法中使用它,具体取决于您希望如何管理 DataAcessor 的生命周期。
It would result in a big mess. If you are adding 2 items simultaneously from different threads, you would certainly end up with very strange results, or even errors if one thread closes the
DataAcessor
before the other completes.I would use a local
DataAcessor
or create a new and use that in all the methods depending on how you want to manage the lifetime ofDataAcessor
.我总是更喜欢非静态类。依赖项无法注入静态类,并且单元测试更加困难。此外,它的客户在进行单元测试时不能用测试替身替换它。
http://googletesting.blogspot.com/2008 /12/static-methods-are-death-to-testability.html
I always prefer non static classes. Dependencies cannot be injected to an static class and unit tests are harder. Also, its clients cannot replace it with a test double when they are unit tested.
http://googletesting.blogspot.com/2008/12/static-methods-are-death-to-testability.html
该代码不是您编写的线程安全的方式。
如果您有像这样的 dataAccessor 字段和静态方法,那么您将遇到多个客户端同时访问此代码的并发问题。您可能会发生非常奇怪的异常,甚至可能一个客户端可以看到另一个客户端的数据。
摆脱这些方法和该字段上的静态,并为每个客户端实例化 SampleDao 的新实例。
this code is not thread-safe the way you have it written.
if you have the dataAccessor field and the methods static like this, you will have concurrency problems with multiple clients hitting this code at the same time. it's likely you'll have very strange exceptions occuring, and even possible that one client could see another client's data.
get rid of static on these methods and this field and instantiate a new instance of SampleDao for each client.
在每个方法中将新的 DataAccessor 对象分配给静态 DataAccessor 引用将导致并发问题。您仍然可以在 SampleDao 类中使用静态方法,但请确保删除对 DataAccessor 的静态引用。要使用 DataAccessor,请创建一个本地实例。这样您就可以避免并发问题。这里的缺点是每次调用静态方法时,都会创建一个 DataAccessor 实例。
在大多数情况下,Daos 是无状态的。在这些情况下,我认为在 Daos 中使用非静态方法没有意义,因为我们需要创建该 dao 的实例来访问其方法。
Assigning new DataAccessor object to static DataAccessor reference in every method will result in concurrency issues. You can still have the static methods in SampleDao class but make sure you remove the static reference to DataAccessor. To use DataAccessor, create a local instance. This way you can avoid concurrency issues. The disadvantage here is every time you call the static method, an instance to DataAccessor is created.
Daos in most cases are stateless.In those cases I see no point in having non static methods in Daos, because we need to create an instance of that dao to access its method.
布鲁诺是正确的。但是,您也可以添加一个单例并使用“锁定”来单线程应用程序的该部分。但请记住,请求将会排队,如果您的查询需要时间,您的应用程序的性能将会下降。这在网络应用程序中尤其明显。对于移动或桌面应用程序,“锁定”绝对是合适的。
Bruno is correct. However, you could also add a singleton and use "lock" to single-thread that part of your app. Keep in mind, though, that requests are going to queue up and if your query takes time your app's performance will degrade. This is especially noticeable in a web app. For a mobile or desktop app "lock" is definitely appropriate.