Ado.net - N-tier

yop

Guys,
Any good sites or books to give me an insight into N tier design with ADO.NET??

Currently we have an N tier design using a COM+ object to handle the Db interaction, executing or returning data.

We then use a VB class to interact between this and the UI. How does this sit in ADO.NET.

Bit of an open ended question but really what I want to know is best practise really with regards to ADO.NET with a SQL Server back-end.
All SQL will be processed by SQL Server.

Thanks

Ginger

What you can do is abstract it, into a datamanager. This manager implements the functions such as connecting to the database, initialising trasactions and performing all your database stuff..

Along the lines of ..

Implement your datamanager, so that it has executes transactioned SQL, SP, Dataset operations. When the object is initialised it creates it connection etc.. using whatever client you need eg SQLClient,OLEDB etc

In your business logic ... create a new datamanager. Call method.. dispose manager

Bit flaky explanation but if you diagram it, its quite easy

stevenmu

I found these article quite usefull


http://www.microsoft.com/belux/msdn/nl/community/columns/hyatt/ntier1.mspx
http://www.microsoft.com/belux/msdn/nl/community/columns/hyatt/ntier2.mspx
http://www.microsoft.com/belux/msdn/nl/community/columns/hyatt/ntier3.mspx

yop

You are talking about using the Data Application blocks Ginger are you?
I had intended that alright but since currently we have a "ProcessRequest" method which either returns an ADO recordset or just execute an SQL Query, where in this you can return a Datareader, Dataset etc.

I may just need to add a new method to return a reader or a recordset.

Thanks Steven, I must look at this.

Ginger

If you look at the 6 tier model of the links provided above thats fairly much what i am saying.. its the current way that I am working with a project.. we basically dont send any SQL to the DB its all done via Stored Procs...

Also at the business logic layer we get back datasets or collections of objects rather than readers or views..

So Presentation -> Workflow -> Business Logic -> Database Logic -> Database Layer -> Database

Our Database logic is our datamanager. It removes a lot of the need to know what database we are using or if we need to change how our stored procs are handled.

I am fairly such what you have done in your VB stuff is fairly much the exact same

yop

Thats it Ginger, all SQL been excuted in SP's, I should have said executing the stored procedures.

You you always return a collection or a dataset?
Your datamanger is defined by yourself is it?
Do you make any use of the the MS Data Application blocks?

Ginger

Our DataManager returns Scalar, Datasets, Booleans whatever, our Business logic either converts them to other objects or leaves them as is.........

Havent used the Data App blocks yet, well not on this project anyways. I know we have mentioned them in the design meetings, its a case of our datamanager is a shared component throughout different apps