Hi Paul,
Being that it is a small app, putting the data access and business logic
directly into the class probably won't cause you huge headaches down the
road. Normally I create a Business Layer that handles logic, calculations,
and validation. For example, to validate that the class is correctly
filled. Then I'll dump that to my Data Access Layer, which will handle
sending it to SQL or disk or whatever. Both the Business Layer and Data
Access Layer generate Error objects which can be consumed by my Error
Reporting Layer that works closely with my UI to dish error results back to
the user. If for no other reason, you could implement this (which shouldn't
take too long for a small project) just to get some experience in piecing
together an enterprise level solution. But like I said, putting everything
into your classes and collections probably won't cause you regrets. For
example, switching your data access from disk to SQL in the future in a
small app isn't nearly as much of a hassle as it would be if this was a
gigantic project with a dozen developers on it. You are writing all the
code so jumping back into it won't be so bad. Good luck! Ken.
--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
"Paul" <pa**@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Hello,
I'm upgrading a small single user app to VB.NET and have a few questions
about loading classes & collections classes with the data from a one to
many dataset structure.
I'm serializing the data to disk as a dataset and was wondering if it was
an accepted practice to load/add/edit/delete the data in the dataset from
methods within the collections/classes or should I just use them as a
container, managing all dataset transactions externally.
Simplified structure:
Parent Class (Each related Child collection is accessible from within
Parent Class)
Parent collection class
Child Class
Child Collections class
Hope thats clearer than mud.
Thanks.
Paul