Static DataAccess

Coordinator
Feb 4, 2008 at 12:49 AM
This discussion is open following the issue #9277:

kolken said:

_Your generator is very nice. Made exactly for doing the thing I did by hand last time (very boring and time consuming and useless, of course).
There was only one big difference. You create (and destroy) Dal object and also DataAccess object for each query. Using static Dal object (I mean created once as a static Bll object attribute) and the same for DataAccess (can be completly static class with only static methods) would be much better. SqlCommands and SqlParameters should be dealt with locally in Dal otherwise synchronization is necessary.
I started rewriting the DataAccess (attached) but I don't know the code very well. _

This subject is always difficult to handle. Static or not. I've been asking myself quite long about this and decided to write a non static data access class. The main reason of this choice was that anyway connections are handled in the SqlConnection pool. By the way there was a good reason i can't remeber.

The thing is that you can write your own plugin to generate static code instead of a non static one. I will be glad to help.
Feb 4, 2008 at 10:57 AM
I'm afraid I don't need to write a plugin for static code. It's not extremely important. It's a pity you don't remember the main reason for non-static data access class. From my point of view creating and destroying object are the most time-consuming operations in the .NET (but the complexity is anyway O(1)). So in this case I would choose static data access. It is my opinion. You don't have to care about Dispose() everytime.
Coordinator
Feb 4, 2008 at 7:09 PM
I agree with time consumption, and as i remember why i chose not static data access, i will expose my point of view:
When you use, Datareader, they are connected and linked to a specific connection. If you use a static connection, you cannot create 2 DataReaders on this connection. Of course there is the "CloseConnection" behaviour of the Datareader but i never found it very smart. I've met many problems using datareaders (anyway i'm not sure Datareaders are used in the generated code).

Dispose in the case of the connection to a Database is of much importance. Look at the code of the Dispose method of a SqlConnection, it does a lot of things.

In the previous version of the tool, all generated code was non static and i used it for a client. I never had performance issues. It depends on the way you use your datas. For me, i prefer simple request called multiple times (and so use the cache of SqlServer) than having long time processing requests.

Does anyone has an idea of what is the best way to implement the dataaccess? Static or non static?
Feb 4, 2008 at 8:42 PM
I didn't use DataReaders (instead Bll objects - entities were created in Dal - which makes it more complicated => cyclic dependencies), so that's probably the main reason. Just about that connection, could SqlConnection be static or not? So it could be just opened and closed but not disposed everytime used. I don't know.
Coordinator
Feb 5, 2008 at 7:45 PM
If the connection is static what will happen on web sites? The connection will be alive as long as a user uses the site isn't it?
I'll check this asap -> This means creating a new DAL generator just for the DAL Access class. But it can take less than an hour... Is the DataAccess File ready to use with a static connection? When do you open your connection? When the app starts?
Feb 5, 2008 at 8:25 PM
Sorry, it's a nonsense to have a static connection. It must be created for each request.
We may close this discussion unless someone else has more experience with static vs. non-static dataaccess.