Andreas, Look into using Typed DataSets for dealing with your domain data. You can graphically draw your data structure (parent-child relationships, etc) and VS.NET (or the XSD.EXE tool) will generate a subclass of System.Data.DataSet which will have properties and fields named after your table and columns.
You can use a DataAdapter to Fill() the DataSet and you can use the Update () method to save changes back to the database if required. If you prefer more control you can fill the DataSet "manually" (perhaps using DataReader) and use Command objects to update the DB. At some point in the fusture there will be a more esoteric persistency mechanism (called ObjectSpaces) but I think DataSets are good enough for most scenarios. Hope that helps, Duncan Smart ============== On Tue, 30 Apr 2002 01:27:00 +0200, =?iso-8859-1?Q?Andreas_H=E5kansson?= <[EMAIL PROTECTED]> wrote: >I'm planning to develop a system that consicts of one www section >and one application section. The system is an e-Commerce system >that uses the www side as a presentation layer and the windows >application as a manager utility to manage the contents of the >e-Commerce site. > >From what I have been able to understand the best approach to >design such a system is to use an n-tier solution and based on that >I have this on the clear. > >(1) PRESENTATION LAYER >This part is the www application and the windows based >application for managing the e-commerce site. > >(2) BUSINESS LAYER >This is where the heart of the application is designed in a >set of classes thats incoroprates the business rules and such. >They are arranged in a hierachical structire to support a good >plugin framework that will be exposed by the windows >application presentation layer. > >By the way. Since my plugin framework is based on the >business layer, but I need to add some extra classes that >deals with manipulating the uder interface of the windows >application. How would I merge these two into a single >hierahical structure in my presentation layer ? > >(3) DATA LAYER >Here is a fuzzy section. I'm not quite sure if I need to have a >persistency layer or not. The whole concept of adding a >persistency layer was introduced to me when I asked a >question on how to imperssonate a collection class but >have it reside directly ontop of a database instead. > >Imagine my hierahical object model > >Application > Customers > Customer > Products > Product > >Now both Customer and Product are derived from an Item >class, but the Customers and Products classes need to act as >a collection class, but not having to pre-populate them for >obvious reasons. Thats what I want to develop a class that >acts like a collection class but instead it featches data directly >from the database. > >I dont have a problem of making the class so queries are >included in each "collection" class, since this will only be >running on a SQL Server that I'm sure of. I would like to >use an existing (is this whats called a legacy database?) >that was designed about 6 months ago. > >So is there a need to use a persistency layer or is that >aiming too high for my requirements where I will be >happy to hardcode queries in "collection" classes or >ven use stored procedures to select/delete/update the >various kind of objects. Or does anyone have >ANY suggestions / articles / code that shows how >to write a fake collection class that resides directly >ontop of the database and fetches data from it when >needed. > >It should expose the same interface as a normal >collection, but not store data internaly. > >-- >Andreas Håkansson >Student of Software Engineering >andreas (at) selfinflicted.org > >You can read messages from the DOTNET archive, unsubscribe from DOTNET, or >subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
