C# datalayer architecture - comments please!

[Ranier Dunno]

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!

[Nicholas Paldino [.NET/C# MVP]]

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]
- mv*@spam.guard.caspershouse.com

"Ranier Dunno" <an*******@discussions.microsoft.com> wrote in message
news:97**********************************@microsof t.com...

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!

[mikeb]

Ranier Dunno wrote:

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!

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

http://msdn.microsoft.com/library/en...ml/daab-rm.asp

--
mikeb