Question

First, let me explain what I am doing. I need to take an order, which is split up into different databases, and print out this very large order. What I need from the orders is about 100 or so columns from different databases. The way I was doing in was querying with a join and assigning all of the column values to a variable in my one large Order class. This has started to become troublesome. I am wondering of instead of having one class that is comprised of 100 or so members that make up the order. Should I have just one class for every database I use, and then work with that?

Let me add to this. Basically, is it better to map you objects to the original database tables, or the result set. Because I have my object mapped to the result set and not the individual tables.

Answer 1

I’m going against the grain here, but I’d say that keeping this object mapped to the result set, and keeping the join in the database, might be a better idea.

For the business logic, an ‘order’ is usually a single cohesive concept (at least, that’s how you started out framing it). Could the fact that it is mapped into multiple tables (or databases) be an artifact of how the data is captured? I would ask myself these questions before breaking it up:

• Are there tangible benefits to composing the order out of other objects?
• Do the attributes have different cardinality? I.e. are some per-order and others per-line-item?
• Can you reuse existing code for the composed objects?
• Are you enabling some other interaction that’s easier to do with multiple objects?

If you don’t answer yes to any of those questions, I’d wager your code will be simpler and more readable if it deals with just the order as an atomic object, and lets the database hide the complexity of where it’s coming from (you could even use a view for that).

Sheer number of attributes isn’t usually a reason to break up an interface. But, if the complexity (or size) of the order object itself is what’s getting you down, you might try to simplify it internally to use some sort of generic accessor method, like:

private object GetOrderAttribute(string attributeName){     // use a data structure (like a hash table) to store and access internally } ... output('Quantity: ' + GetOrderAttribute('quantity')); // etc. 

One other note: while performance should rarely be your starting concern in logical system design, most cases involving database table joins will perform better if the database does the join, because the DBMS can use indexes and other mechanisms to perform the join efficiently and avoid loading pages from disk that aren’t needed. Maybe all your individual queries do that too, but typically that’s something the database can do an order of magnitude more efficiently than business logic code. (Of course, if the join is across physical database boundaries, that benefit might be lost.)