These past few days I had a couple of shocking discoveries in some of our libraries. Not sure if there's an official term for it (maybe code smells?), but basically these are my discoveries:

• A view class is being decorated with methods that belongs to a business logic class. Some of these methods provide validation logic, while some others are doing business logics inside the View class.
• A business object class has methods that takes in a view object as one of its parameters

To me these are just not right at all. In the first example, the view class should not be doing any complex processing that relates to business object. If a view class contains business logics, that would mean I have to use the view class to reuse those business logics. Classes that belong in the view layer are responsible solely to display or update the view based on a given model. Any processing logic that doesnt involve in displaying or updating the view, let alone doing stuffs to the business object, should be delegated to the business logic layer. The only exception to this is when the interaction between the view and the business object is simple enough. Simple operations like setting properties of the business object that requires no business logic at all.

In the second example, the business object class should know nothing about the view class. It doesnt make sense to pass your GUI to your business object, What the hell is it going to do with a GUI anyway? A business object should not directly change a view state in anyway. Im a pure believer that classes in the business object layer should be as light as possible. Business object layer has a sole purpose to represent your model in memory and perform CRUD operation to the data layer. If your business object is doing logics other than CRUD operations, those logics should be refactored out to the business logic layer.

Speaking of software layers here is the basic view of software layer stack to my understanding:

Idealy, the responsibility of each layer is as follows:

• A View class is responsible to initialize, update, and displaying GUI to the user. Any communication between a view and a model should utilize a controller class to do the job. As stated above, the only exception here is when the interaction between a view to a business object is simple enough (requires no business logic).
• A Controller class is reposible in controlling actions. It decides what action to take when there is a change in the model OR when there is an interaction between the user with the view. This may be updating a view or executing a business logic.
• Business Logic is where you put all your domain's or model's logic.
• Business Object represents Your domain model in memory as an object. It may communicate directly to the data source or it may utilize an entity class to abstract data source.
• Entity is an object representation of your data source. Why not use business object instead? If you use your business object, you are essentially coupling your business object to your data. This means if the datasource change you're screwed. Moreover, you don't want to make your business object class dirty with all those data mappings logic.
• Data is your data source.

These layers should be implemented as loosely coupled as possible to achieve better design for greater reusability and flexibility. By doing the examples aboves you are basically coupling some of these layers together, because its doing more than it should. Any class should only has only one responsibility. If a class has more than one responsibility, then you should consider refactoring it.

RWendi