Application Development Meanderings

As I go through and implement my DAOs, I noticed that the generic DAO defined by the hibernate site and in books is a good design and has features that I like. However, Spring recommends the use of HibernateTemplate to get uniform exceptions thrown regardless of the underlying data access mechanism. I like that as well. The problem is that when combined with my long conversations (see a previous blog), it all gets quite messy. However, one option that allows me to write non-HibernateTemplate based DAOs is where you can annotate the DAO with a @Repository attribute then place the following definition in your application contexts where the DAO is defined: <bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/> If you have a hierarchical set of app contexts, the above bean definition must be placed in each bean definition. The only issue is whether the DAO needs to keep the session state or not. If so, the the DAOs cannot be used acr

The more I look into the property support in WPF the more I think was correct in calling out that it is nothing more than a type-safe way of having extensible properties for beans. This is like the DynaBean in apache commons beanutils for non-class defined properties (but borrowing from others) and standard bean properties. Since you want change notification and other features in your properties, the DependencyProperty mechansims help you define properties that have nice bean setters/getters in your class while attached properties help you define a property in any class, and use it a class that implements DependencyProperty . Let's see how to do this differently. Suppose you define the interface: public class DependencyObject { public Properties getProperties() { return ... } public void setValue(String key, Object value) { getProperties().setProperty(key, value); } public Object getValue(String key) { return getProperties().getProp

I was looking at WPF's property system ( here ) and notice that one item that is going on is that the property system is really designed to allow a multitude of objects to expose properties for XAML usage. That's a good thing. The other component (with attached properties) was to allow the ability of other objects to share values between different, unrelated objects. These objects may exist in a hierarchy or not. In this way, the property could be thought of as a shared value and that is what a ValueModel (from jgoodies and smalltalk) do. An attached property also allows unrelated objects in a hierarchy to declare properties that the higher-up object wants the lower object to define. Then the higher-up object can access the lower-object's specific values. This is sort of like extending an unrelated class with a property that is defined in another class but doing this quite manually. This last use case could be implemented by ValueModel's. The parent object could have a

My application has all of the resource stored in a database. It is entirely database driven. I want to provide a navigatable view of the these resources in my RCP. Using the common navigator framework (CNF) I can provide a view to navigate these resources rather generically. However, the classic problem is that while the toplevel objects in the CNF are defined logically in the application many of the lower level resources (in the tree view) are going to be from the database. For example, the top level resources have contacts and security objects. I represent these directly in code similar to IResources in the eclipse world. However, the list of contacts come from the database directly and are represent as domain objects using an ORM with a persistent context (long conversation). So if I want to have menu commands defined on those database resources, I can certainly do so but I often need to calculate the application-level logical object so I can perform operations on the group, et