I want to change a flag on a series of objects. What is the standard DAO practise for:
Changing a property of all objects represented in a table?
Merging a list of objects?
You stumbled upon one of the things where the classical DAO approach can often lead to bad performance. Depending on your persistence engine, it will be extremely tricky to turn this into ONE efficient UPDATE statement instead of having to update hundreds of objects individually.
I would look at my business objects, estimate the amount of objects one can change at the same time and measure the impact on having a 'pure' oo domain model (which usually boils down to iterating through those objects and changing them one at a time) or adding a custom method that will do a batch update call for just this situation.
Related
I am wondering which approach is better. Should we use fine grained entities on the grid and later construct functionaly rich domain objects out of the fined grained entities.
Or alternatively we should construct the course grained domain objects and store them directly on the grid and the entities we just use for persistence.
Edit: I think that this question is not yet answered completely. So far we have comments from Hazelcast,Gemfire and Ignite. We are missing Infinispan, Coherence .... That is for completion sake :)
I agree with Valentin, it mainly depends on the system you want to use. Normally I would consider to store enhanced domain objects directly, anyhow if you would just have very few objects but their size is massive you end up with bad distribution and unequal memory usage on the nodes. If your domain object are "normally" sized and you have plenty, you shouldn't worry.
In Hazelcast it is better to store those objects directly but be aware of using a good serialization system as Java Serialization is slow. If you want to query on properties inside your domain objects you should also consider adding indexes.
I believe it can differ from one Data Grid to another. I'm more familiar with Apache Ignite, and in this case fine grained approach works much better, because it's more flexible and in many cases gives better data distribution and therefore better scalability. Ignite also provides rich SQL capabilities [1] that allow to join different entities and execute indexed search. This way you will not lose performance with fine grained model.
[1] https://apacheignite.readme.io/docs/sql-queries
One advantage of a coarse-grained object is data consistency. Everything in that object gets saved atomically. But if you split that object up into 4 small objects, you run the risk that 3 objects save and 1 fails (for whatever reason).
We use GemFire, and tend to favor coarse-grained objects...up to a point. For example our Customer object contains a list of Addresses. An alternative design would be to create one GemFire region for "Customer" and a separate GemFire region for "CustomerAddresses" and then hope you can keep those regions in sync.
The downside is that every time someone updates an Address, we re-write the entire Customer object. That's not very efficient, but our traffic patterns show that address changes are very rare (compared to all the other activity), so this works out fine.
One experience we've had though is the downside of using Java Serialization for long-term data storage. We avoid it now, because of all the problems caused by object compatibility as objects change over time. Not to mention it becomes headache for .NET clients to read the objects. :)
I am in the process of designing a new java application which has very strict requirements for auditing. A brief context is here:
I have a complex entity with multiple one to many nested relationships. If any of the field changes, I need to consider it as a new version of the object and all this need to be audited as well. Now I have two options:
1.) Do not do any update operation, just insert a new entity whenever anything changes. This would require me to create all the relational objects (even if they have not been changed) as I do not want to hold references to any previous version objects. My data tables becomes my auditing table as well.
OR
2.) Always do an update operation and maintain the auditing information in separate tables. That would add some more complexity in terms of implementation.
I would like to know if there is a good vs bad practice for any of these two approaches.
Thanks,
-csn
What should define your choice is your insert/update/read patterns for both the "live" data and the audits.
Most commonly these pattern are very different for both kinds.
- Conserning "live" it depends a lot on your application but I can imagine you have significants inserts; significatant updates; lot of reads. Live data also require transactionality and have lot relationship between tables for which you need to keep consistency. They might require fast and complex search. Indexes on many columns
- Audits have lot of inserts; almost no update; few reads. Read, search don't requires complex search (e.g. you only consult audits and sort them by date) and indexes on many columns.
So with increased load and data size you will probably need to split the data and optimize tables for your use cases.
I am trying to figure out best practice for N-Tier application design. When designing the objects my UI needs and those that will be persisted in the DB some of my colleagues are suggesting that the objects be one in the same. This doesn't not feel right to me and I am ultimately looking for some best practice documentation to help me in this decision.
EDIT:
Let me clarify this by saying that the tables (Entity Classes) that are in the DB are identical to the objects used in the UI
I honestly do not understand why I would want to design this way given that other applications may want to interact with my Data Access Layer....or it is just ignorance or lack of understanding on my part.
Any documentation, information you could provide would be greatly appreciated. Just want to better understand these concepts and I am having a hard time finding some good information on the best practice for implementing these patterns (Or it is right in front of me on what I found and I didn't understand what was being outlined).
Thanks,
S
First of all, DAOs and database entities are two very different things.
Now to the question. You're right. The database entities are mapped to a database schema, and this database schema should follow the database design best practices, and be normalized. The UI sometimes dislays exactly the information from a given entity, but often show data that comes from multiple entities, in an aggregate format. Or, to the contrary, they only show a small part of a given entity.
For example, it would make sense for a UI to show a product name, description and price along with the name of its category, along with the number of remaining items in stock, along with the manufacturer of the product. It would make no sense to have a persistent entity containing all those fields.
In general and according to most "best practices" comments, yes, those two layers should be decoupled and there should be separate objects.
BUT: if your mapping would only be a one-to-one-mapping without any further functionality in the non-database-object, why introduce an additional object? So, it depends. (as usual ;-) ).
Don't use additional objects if the introduced overhead is bigger than the gain. And don't couple the two layers if re-usability is a first-class-goal. That may not be the case with some legacy applications, e.g.
I have a persistence layer that serves data to many clients. I also have a table structure that is normalized, which means values are spread across tables. I want to design my persistence service to ensure services that depend on it do minimal round trips: not more than one, if possible.
Given this, what should I focus on for an elegant solution?
1. Do I ensure the clients can indicate the portion of the object graph they want during the fetch? (thereby reducing round-trips) [eg: fetch(parent, list<child-object-name>) ]
2. Do I ensure I provide common methods such for hydrating portions of the object, along with basic fetches? [eg: hydrate(parent, list<child-table-name>)]
3. Do I provide basic information to start with (for example, object graph to depth 1 only / only look-up-table objects,) and the rest only upon request?
I understand, there are many many discussion on the net, with very good information. I did read a few as well:
* http://forum.springsource.org/archive/index.php/t-23439.html
* How can I access lazy-loaded fields after the session has closed, using hibernate? (answer by Paul Adamson)
* Deep Object Graphs Hibernate
however, most of the answers hover about 'do what suits you best'. What do programmers usually do in this situation?
Don't make a generic one-size fits-all persistence layer. Write persistence methods specifically for the functional use-cases you're implementing.
While doing it, you're probably going to meet cases where a persistence method, or some part of it, can be reused across two or more use-cases. This will probably force you to rename the method to make it more generic (less coupled to one specific use-case), or refactor to extract the common part. But if you want the best performance for your app, you're going to need specific queries for specific use-cases.
How should one go about filtering a series of domain objects according to user-defined criteria? Should the filtering methods be in the model or should they be in the DAO?
If you want to use your model objects only (mainly) as data containers you should put the filter into the DAOs you are already using. It is a good practice to make sure, that the user defined criteria are database independent (so pass your own filter object instead of plain e.g. Hibernate Criteria. query by example may work great, too).
Then your DAO methods can look like this:
public interface BeanDao
{
List<Bean> findAllByFilter(BeanFilter filter);
}
The choice of whether to retrieve a greater number of objects and then filter or simply to retrieve the correct objects in the first place depends on the underlying data. Most applications will use a combination of the two.
The things I would consider are:
Network bandwidth & Memory requirements
If after filtering there are a small number of results but a significantly larger number of results before filtering then it could be a waste of bandwidth and memory resources to do the filtering in code.
Query speed
Filtering the results in the database can be more expensive than doing the logic in code - disk vs memory. Indexes are required to make it worthwhile.
Maintainability
Creating new queries can be time consuming. It will definitely mean writing some sql and revisiting various phases of testing. It may require modifying the db schema such as adding an index to speed up the query.
When solving this problem in Java it might be worth considering the visitor pattern. I often use two interfaces SingleMatcher and MultipleMatcher to filter a collection of objects. Implementations of these can be combined to create new user-defined criteria. Another advantage of this is that once you have a the matchers users may want to use you won't have to go back to testing to create new criteria.