tags:

views:

30

answers:

1

I'm building a small financial system. Because of double-entry accounting, transactions always come in batches of two or more, so I've got a batch table and a transaction table. (The transaction table has batch_id, account_id, and amount fields, and shared data like date and description are relegated to the batch table).

I've been using basic vo-type models for each table so far. Because of this table structure, though, transactions will almost always be selected with a join on the batch table.

So should I take the selected records and splice them into two separate vo objects, or should I create a "shared" vo that contains both batch and transaction data?

There are a few cases in which batch records and/or transaction records are loaded individually, so they will each also have their associated vo class. Are there possible pitfalls down the road if I have "overlapping" vo classes like this?

A: 

The best approach is to tie models not to database tables, but to your views. E.g. if view has date field, then use "shared " view object (ideally even specific-to-the-view object), if view has only transaction info, use another object etc. It can be tedious, but separation of concerns will be worthy. Too much duplication can be remedied with reusing/inheriting when appropriate.

ovolko
Do you mean "view" in the database sense, or something else?
keithjgrant
"View" in a MVC sense. E.g. form, page etc.
ovolko
Ah, gotcha. I had my head stuck in the data access layer. Thanks!
keithjgrant