C# datalayer architecture - comments please!

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi

I'm writing a datalayer for a C# application. Currently, I've implemented it using the following main components

- An interface called IDataAcces
- A singleton object called DataAccess implementing that interface
- A static class called SqlQueryBuilder which is used by DataAccess to build dynamic SQL queries
- A static class called SqlWorker which is used by DataAccess to execute SQL queries
- A static class called DBAccess which delivers database connections to SqlWorker

Is this a decent architecture? I'm kind of thinking it's not very object oriented... but is that a problem? If so, why? Any thoughts would be greatly appreciated!
 
Ranier,

While the interface is a good idea, I don't know of the value of it if
you are going to have a singleton.

I am curious, why not just have a class that has references to all of
these to do it's work? Have a class that implements your interface, then
uses SqlQueryBuilder, SqlWorker, and DBAccess internally to perform its
work.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Ranier Dunno said:
Hi,

I'm writing a datalayer for a C# application. Currently, I've implemented
Click to expand...
it using the following main components:
- An interface called IDataAccess
- A singleton object called DataAccess implementing that interface.
- A static class called SqlQueryBuilder which is used by DataAccess to build dynamic SQL queries.
- A static class called SqlWorker which is used by DataAccess to execute SQL queries.
- A static class called DBAccess which delivers database connections to SqlWorker.

Is this a decent architecture? I'm kind of thinking it's not very object
Click to expand...
oriented... but is that a problem? If so, why? Any thoughts would be greatly
appreciated!
 
Ranier said:
Hi,

I'm writing a datalayer for a C# application. Currently, I've implemented it using the following main components:

- An interface called IDataAccess
- A singleton object called DataAccess implementing that interface.
- A static class called SqlQueryBuilder which is used by DataAccess to build dynamic SQL queries.
- A static class called SqlWorker which is used by DataAccess to execute SQL queries.
- A static class called DBAccess which delivers database connections to SqlWorker.

Is this a decent architecture? I'm kind of thinking it's not very object oriented... but is that a problem? If so, why? Any thoughts would be greatly appreciated!
Click to expand...


You might want to compare it with the MS Data Access Application Block
to get ideas:

http://msdn.microsoft.com/library/en-us/dnbda/html/daab-rm.asp
 
Back
Top