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.)