Hello Ben,
"Ben" <Be*@discussions.microsoft.comwrote in message
news:42**********************************@microsof t.com...
>I have a Customer table in the database that relates to a CustomerType
table
(I have several other table combinations in the database like Document and
DocumentType).
As far as I can tell, I have several ways of defining the Customer class:
1) Use inheritance, where I will have an abstract base class CustomerBase
that other, concrete customer class can subclass, i.e. Private, Company
etc.
2) Use composition, so the Customer class would contain a CustomerType
class, exposed as a property.
3) Similar to the second option, but instead of a class, use enum, exposed
too as a property (perhaps instead of an enum, the class would use an int,
just like the Customer table in the db).
What is the right way of defining these type of classes please? I want to
be
able
to show instances of them in a grid, or some other type of display, being
able to filter out types that don't belong to the criteria, for example if
the user is looking at the customer list, he would be able to filter rows,
by
using a ComboBox for instance.
Welcome to the Object Relational Impedence Mismatch.
In Relational design, you are trying to isolate data duplication through
normalization. Therefore, in your relational model, you create
relationships between independent variables. In this case, Customer and
CustomerType. This reduces duplication and allows for very efficient query
processes.
But in OO development, you are not trying to make your data efficient (per
se). You are trying to encapsulate things that vary while exposing
commonality. It's a different mindset.
For CRUD-style applications, you can bring the data-oriented thinking
straight up to the surface. You can query into your app a memory-copy of
the entire CustomerType table (in a dataset). Then, when you retrieve a
Customer row, you can look up the related data from the dataset of
CustomerType. You can also use this dataset to prepopulate drop-downs or
validate data entry.
For applications that encode business rules or manage workflow or need to
drive functionality based on the customer type, you have a different
problem. In that case, the data values are merely shadows of the business
rules you are trying to implement. In that case, look to design patterns to
help you out.
For example, if the selection of a particular customer type infers that a
specific taxation method must be used, then a Strategy pattern may need to
be used, along with a factory method, to encapsulate the logic to decide
what strategy to use. If you need the behavior of the Customer object
itself to change based on the selection of Customer Type, then the State
pattern may be more helpful. (For example, if a 'High Value Corporate'
customer has the ability to apply for an extention of credit wherein a
'Retail customer' does not... the ApplyForCredit method would behave
entirely differently).
I hope this helps,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
