views:

28

answers:

1

I'm trying to make a deliberate effort to write code that follows proper convention, even when it might add complexity, and so far I've succeeded but I'm noticing a trend in my programs.

My project is small, a javaee webapp with only a handful of servlets, follows MVC design, and makes use of beans as the model. My problem is that my beans are more often just 'a place to stick something so I can get a decent view coded'. I got the impression that beans were of course just containers for data, but also meant to have some portability and usefulness beyond a single servlet.

Is my problem just the result of relatively simple code or am I likely misusing the concept of a bean ?

A: 

Beans are supposed for data storage. We are talking about Pojo Beans. If collections are not enough to handle data model the app works with, class is created that fits the needs. BEAN should be considered just an object for temporary state preservation having setters and getters that might have light additional functionality. There is nothing wrong when your application operates with a lot of beans, if you adhere to paradigms like inheritance and polymorphism.

Pojo Beans also captures data model (domain model) of your application if it runs on a database ... database tables and beans corresponds to each other. That's how ORM works (persisting the state of a bean in time and the other way around). Even without ORM, Domain Access Objects layer operates well on a domain model compound of many beans.

They are also the best way for view presentation. Mixing them with collections. Implementing comparators.

The term "bean" started to be used in Spring framework for instance, where it is just a class that is part of application context / Spring container not a getter/setter JavaBean at all.

lisak
I'm finding that my (pojo) beans vary in detail only by one or two fields. In that respect, they are becoming coupled to the view. I guess its just inevitable sometimes ?
JHarnach
@JHarnach, look, the fact that 3 different beans vary in 3 fields and otherwise shares the other 10 fields is bad design. In this case you are free to use inheritance, childBean extends parentBean. It is easier when one can use Generics, because it enhances using polymorphism. Creating Generics collections instead of casting types from parentBean to childBean whenever you have ArrayList<ParentBean> and want to get childBeans.
lisak