Question

I often have the same trouble when I have to design my class for a web application. The requirements are :
– maintainable (no copy-paste for instance)
– layers fully separated (the business layer doesn’t have to know which method of the data layer is used)
– high performance : don’t load useless data.

First I have a table with all my customers and their addresses :
Code :

Customer
--Id
--Name
--Address
----City
----ZC
----Street

Now I want a table (in another page) with all my customers and the books that they bought, I have a few possibilities :

1/ I create a new class :

Code :

CustomerWithBooks
--Id 
--Name
--Books[]
----ID
----name

PRO : I load only the useful data
CONS : I build my class after my UI , and there is copy-paste.

2/ I add Books[] to the first class.
PRO : Everything is in the same class, it’s maintainable
CONS : I load the address for nothing. If I don’t load the address I can : lazy loading, but I really don’t like it, or when I use my class I have to know which method of my DAL i called, and I don’t like it.

3/ I use inheritance :
Code :

ClientBase
--ID
--Name

ClientWithBooks : ClientBase
--Books[]

ClientWithAdress : ClientBase
--Address

PRO: really maintenable, and I don’t load data for nothing
CONS : What do I do if in one UI I want to show the Books AND the Address ?

4/ ?? I hope there is a perfect solution

Answer 1

You option 1 is close to good, assuming I understand it correctly. A customer and a book are two completely different things. You want that data/functionality separate, and should not inherit from any common base class (that you have made).

As the “Con” you say: I build my class after my UI , and there is copy-paste.

• A. If you mock up some UI to help clarify requirements before you settle on your design and code up classes, that’s good, not bad.
• B. Good arrangement of your domain objects helps eliminate copy/paste, not cause it. If you have some seemingly repetitive code within your well-arranged classes (often data access code) that’s typical, don’t worry. You can address with with a good data-access layer/tool, good shared logging resources, etc. Repetitive code within your classes just means you have more design improvement to do, not that having separate classes for all your domain realities is bad.

On the page where you need to deal with both customers and books, you will use customer objects and book objects, and probably a books collection object. And depending on how your db/object-model are set up, you might be dealing with other objects to get form customer to the books they bought. For example, the customers probably buy 1 or more books at the same time, and these are tied to an Order object, which has a reference to a customer. So, you’ll probably go from a

1. Customer to an
2. Orders collection containing all of that customers orders to the individual
3. Order objects and from there to a corresponding
4. Books collection containing all the
5. Book objects that relate to that Order object.

None of these need to inherit from each other. Now, let’s say getting all the books bought by a customer is something you do a lot, and you want to streamline that. You then want to have a Books collection directly off of Customer that gives you that, though the sql queries you use to get those books still goes through Orders in the db. You must start with your object model (and tables behind the scenes) reflecting reality accurately. Even if this give you seemingly many classes, it is more simple in the end. You might end up with some inheritance, you might not.