good architecture for reusing datasets

[bar]

hi,

I am quite new to using datasets on windows forms but the demos seem very
easy. Just drag a connection, adapter and dataset en walking through a
couple of wizards and you have a nice windows form connected to a database.
But if you start making more forms with the same dataset then it is not easy
to reuse the dataset which seems to mee tightly coupled to the view which is
not a good design a guess. Do you have any suggestions how to use ado.net
with windows forms with a better reuse of the datalayer?

Thanks in advance.

bar

 

[Cor Ligthert[MVP]]

Bar,

This is very much in endless books about data layers, middle tiers and
whatever about architecture.

Like most of these things is this mostly in general theoretical with as
argument that the used tools should not influence the architecture.
You know, like a book how to go from New York to Tokyo in the best way, but
telling only that you have to travel using a secure route.
You see seldom how this easily can be done.

(A less theoretical book about AdoNet is from Bill Vaughn, with the for
probably most non native English speakers impossible to remember title
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition))

But to go on, the solution for your question can be done easily in Visual
Studio Net

If you want to make a separate data layer, then simple add a new project in
your solution and choose a library project.

Here I stop about the separated layer, because there is not always a direct
a need for a separated layer.
That is only if your project becomes so hug that more persons have to work
(maintain) with it.

You can simple add from do in the tab Project -> Add Net Items and choose a
"component" (this is a template).

The component you can use to drag your datasets on it and your Data
Processing is nicely separated from your UI.
The component has than by instance nicely for you the right Idisposable
method implemented.

I hope this helps you something with the start to make it better.

Cor

 

[bar]

Hi Cor,

Thank you for helping me to get on track!

Bar

 

[sloan]

Its hard to give quick-tip advice on the subject. But there's a go.

........

Put your datasets in their own assembly.

Do not use the microsoft "auto" (or voodoo as I call them) adapters for
loading them.

Write a (at least one) different assembly.....put your DAL code in there.
Use the .LoadDataSet method (EnterpriseLibrary.Data or DAAB 2.0) to populate
your datasets.
(What the "at least one" means is that you could have multiple DAL
assemblies...using the DataSets. You need at least one, but you could have
several. Aka, this is where the "reuse" of the datasets could happen).

You will find re-use much easier to accomplish, especially hitting different
databases.

You can find some downloadable code (an example of this) here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry

I have 2.0 version, but it doesn't use datasets.

There is a MS "bird's eye view" article I reference at the blog entry above.
Bookmark that MS article and read it today, tomorrow, next week, 1 month
from now.
It will help you understand the pros/cons of different setups.

Note: my advice above (put the DataSets into their own assembly) comes
partially from the MS article.
You will find the advice (in that MS article) around this text

Deploying Business Entities
* Deploying Business Entities implemented as typed DataSets.

 

[sqlguru]

Linq, MVC framework, OR/M, entity model framework, datasets &
datatables are all pathetic hacks in .NET. Only idiots use this 1-2-3-
poof magic application techniques that are guaranteed to fail
longterm.

Get yourself a begineers level book on software engineering and design
patterns.

 

[sloan]

Still waiting for you to answer this one:
http://groups.google.com/group/microsoft.public.sqlserver.programming/msg/c583ff5f67741983?hl=en

//quote// Only idiots use ......... //end quote//
And you still continue with your ad-hominem arguments.
http://groups.google.com/group/microsoft.public.sqlserver.programming/msg/353db1e958137f58?hl=en




Linq, MVC framework, OR/M, entity model framework, datasets &
datatables are all pathetic hacks in .NET. Only idiots use this 1-2-3-
poof magic application techniques that are guaranteed to fail
longterm.

Get yourself a begineers level book on software engineering and design
patterns.

 

[sqlguru]

You've failed to explain this scenario:

That's a concurrency issue. If you ignore the physical tiers and
factor it to the user-level, what happens when user1 performs the
updates, how does user2 through userN know about it? You can choose to
implement optimistic or pessimistic concurrency. The same solution
applies to the physical tiers, in this case the DAL.

Go get a beginners level book on concurrency, application
architecture, and database design.

 

[sqlguru]

You've failed to explain this scenario:
That is a concurrency issue. If you ignore the physical tiers and
factor it to the user-level, what happens when user1 performs the
updates, how does user2 through userN know about it? Now factor in the
physical tiers and you can choose to implement either pessimistic or
optimistic concurrency.

Get yourself a beginners level book on concurrency, application
architecture, and database design.

 

[sloan]

That's a great tip.

Here's another one involving Outlook Express:
http://groups.google.com/group/microsoft.public.sqlserver.programming/msg/698e12113c167a85?hl=en


As with Kevin, you're the first (and now only) person in that list.
Congratulations.

Bye-Bye..........





That's a concurrency issue. If you ignore the physical tiers and
factor it to the user-level, what happens when user1 performs the
updates, how does user2 through userN know about it? You can choose to
implement optimistic or pessimistic concurrency. The same solution
applies to the physical tiers, in this case the DAL.

Go get a beginners level book on concurrency, application
architecture, and database design.