Hi et,
From your question I can see that you are thinking clearly and asking the
right kinds of questions. This is good; it will prevent you from having to
go back and fix a lot of stuff that doesn't work correctly because you spent
some time up front planning. Those who fail to plan, plan to fail! ;-)
I can also see that your understanding of OOP (Object-Oriented Programming)
is somewhat murky, and that is where you need to begin. I have compiled
several links that will help you gain a better understanding, and therefore,
be able to plan your object model more easily, and with better structure:
http://msdn.microsoft.com/library/de...ithObjects.asp
While this is aimed at VB.Net users, the concepts are the same for any OOP
programming language.
http://www.aonaware.com/OOP1.htm
A very simplified, but easy to understand introduction to OOP.
http://java.sun.com/docs/books/tutor...pts/index.html
While this is aimed at Java users, the concepts are the same for any OOP
programming language. In addition, .Net resembles Java in many ways.
http://en.wikipedia.org/wiki/Object-...ed_programming
Very good but somewhat "technical" article, with lots of external links and
references.
A few words to kick you off: OOP is all about organization. It is also all
about abstraction. One of the main ideas of OOP is to think of programming
"things" as "real-world" things. I can see that you have something of an
idea of this. For example, note your use of the word "clients." You speak of
many different *types* of clients, but they are all "clients." Does this
suggest something to you? It should. You use the same word to describe many
different types of real-world entities because they all share some of the
same properties, or attributes. A class is not an object; it is a *type*.
The difference is that an object is a thing, but a type is an idea about a
thing, or a group of things. It is like a definition of the properties that
define what a "type" of a thing is.
For example, you might think of one of Plato's favorite analogies: a chair.
Now, there are many different types of chairs, but they are all chairs. What
do they have in common? The answer is not as simple as you might think.
So, you have a bunch of "clients." That's a good starting point. Now, they
share some things, and don't share others. Within the overall group, you can
create sub-groups of clients that share different types of things. Now, this
is where inheritance and/or interfaces come into play. Inheritance in OOP is
much like inheritance in the real world, but much simpler. It might be
better to stick to chairs. All chairs are chairs, but some are made of wood,
and some are made of metal. So, you could inherit "chair" and create "wooden
chair" and "metal chair." Now you can create many different types of both
wooden and metal chairs, and of course, you can keep sub-dividing them into
more and more categories.
Okay, getting back to clients: Some are Estate clients, some are Real Estate
clients, etc. And Estate Clients would have a set of properties that pertain
to Estates, while Real Estate clients would have a different set of
properties. But some clients might be both, or several of the types of
clients. However, a Real Estate client will always have a certain set of
"Real Estate properties," and an Estate client will always have a certain
set of "Estate properties." And these clients will belong to a number of
differnent categories.
Now, if you were designing a database, you would create a client table, a
Real Estate table, and an Estate table. Each of these 2 tables would have a
"Client ID" column which would identify which clients used that particular
service. There would be a one-to-many relationship between the client table
and each of these "Service" tables. Each client would only have 1 "Service"
record, but each "Service" would have many related client records.
So, as we continue to think about it, notice that I have started referring
to "Services." Sounds like they might have something in common, too. So, we
now have a base "client" class and a base "Service" class. From the
"Service" class we can derive "Real Estate Service," "Estate Service," and
so on. Each "Service" instance would have a Collection of clients, the
people who subscribe to that service. You could call it "Clients" or
"Subscribers." Again, there would be one "client" per client, but
potentially many "Services," so, the "Client" class could have a collection
of "Service" classes. This would represent all the Services used by that
client. Since each "Service" inherits "Service," it would be able to go into
that collection. And since each type of "client" inherits "client" a Service
could have many different types of "clients" in its "Clients" Collection.
I hope that this stimulates your thinking and helps youto get moving in the
right direction. It is brief, but I expect you will read up on the other
resources I posted as well.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
To a tea you esteem
a hurting back as a wallet.
"et" <ea*************@yahoo.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
I am new to asp.net. I am writing a program that will revolve around an
extensive client database, and wonder what the best way to design the
program is, using classes. I have about 10 different sections, or
categories if you will, about a client. For instance, some clients have
data regarding our Estate Planning section, some clients have data
regarding our Real Estate section, etc. Would it be better to have one
object that potentially can contain all data about one client, or better to
have many different objects for each section? The only time we would need
every field for a client is when we're doing reports, most of the program
is getting data in and out for the users. Is this a judgment call?
Wouldn't one object containing everything be quite large, or can I
instantiate it with only the as needed properties each time it's
instantiated. But for maintenance purposes it might be better to have one
object. And maybe this isn't even the best idea, at all.
Thanks for all advice.
