Have you looked at the templates that ship with VS.net enterprise? Would give you a running start
j -----Original Message----- From: Andreas Håkansson [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 7:27 PM To: [EMAIL PROTECTED] Subject: [DOTNET] Aiming to high!?! 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.
