I haven’t done much Java programming and therefore lots of un-answered ORM questions revolve during my mind that may appear as fairly easy to slightly older folks.
Let us say we now have two classes: Customer and Order. Customer class implements a technique known as listAllOrders, what if the method’s signature be?
Set<Order> getAllOrders()// the OOP way
Set<Integer> getAllOrders()// db-friendly way, in line with the assumption that every order is designated a distinctive int id
int getAllOrders()// db-friendly way, optimized
Set<OrderID> getAllOrders()// the OOP way, optimized
Other? A mix of the above mentioned through method over-loading?
My thinking would be to dismiss 3rd option immediately, because the optimisation is premature, uncalled for and will probably cause more trouble than good.
Selecting between your first and also the second options, the primary argument appears to become that in lots of situations coming back an accumulation of orders rather than id’s will probably be an overkill.
The first option would always require pre-loading of orders into memory and even though some order qualities can be remedied through lazy loading an order objects themselves would still require considerably more memory allotted instead of some bare id’s. Another reason appears to become that lazy loading won’t produce the benefit of while using
final modifier to enforce immutability of Order fields.
However, option 2 doesn’t really encapsulate order numbering, i.e. whether it were made the decision to begin using String UUID or lengthy as order identifier rather than integer it might become essential to perform a serious rewrite. Clearly this may be mitigated by introduction of the new lightweight object known as OrderId (fourth approach).
Well, at this time I'd really appreciate the help of ORM and Java gurus!
It always helps to be aware what the caller wants. It is not an optimisation to come back a purchase id if each time, the caller will be going to need to lookup each and every order. However, if more often than not they do not need everything information, then there is not any point in exchange it.
I'd choose option 1 more often than not. But when it is something memory restricted just like a wise phone, I believe I'd choose the lazy expansion.
Among the toughest things for individuals which are a new comer to ORM tools is they attempt to apply the understanding they've from the DB and also the optimizations which were used for the reason that context (storing IDs, etc.). I recommend that you train with objects, and address performance problems when they show up.
Most ORMs handle this kind of concern for you personally Hibernate for instance will automatically lazy-load an assortment (or Orders inside your situation). Internally it'll store an accumulation of the ID values for you personally, but this is actually not your concern because you will only communicate with the item and assortment of connected objects. If you concentrate on your domain objects and think "OO", your ORM tool should give you support and permit you to further optimize later whether it is needed.
I would recommend to make use of option one, because you coping business objects and never playing with amounts. If you want the id, you are able to still obtain it from a purchase. And when you utilize a wise OR mapper, just the primary key of the order is going to be loaded before you access some real data - so no reason to wory about database or memory performance.
I must accept Paul Tomblin, when the function is known as
getAllOrders() I'd expect it to come back a purchase object (presuming this type of class is available). The function ought to be known as
getAllOrderIds() if it is likely to return some thing specific.
Option #2 is, like option #3, a premature optimisation. Your client wants to be aware what the orders are it you possibly will not even care exactly what the orders' IDs are. You will find conditions in which a client may want the IDs, but when the thing is that happening, you need to most likely request Why? and try to operate on the Orders themselves.