Is it mandatory to use Business object for data transfer and work flow?
2 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   mohammad_rizwan
Posted On:   Wednesday, August 3, 2005 11:29 AM

In our enterprise projects we deal with some screens where we add or update some data and again we retrieve that data and display to user in various ways like displaying on screen as a report or viewing in excel etc.. Most of the times, though we identify the business objects based on the nouns in requirements document, really while implementing there will not be any business logic in the objects. Almost all the objects which we identfy as business objects may have methods like add, delete, update and retrieve methods. Still in these cases, is it required to have business objects or can we use transfer object to send the data for saving and retriving or any other pattern/guideline is there for dealin   More>>

			
In our enterprise projects we deal with some screens where we add or update some data and again
we retrieve that data and display to user in various ways like displaying on screen as
a report or viewing in excel etc.. Most of the times, though we identify the business objects
based on the nouns in requirements document, really while implementing there will not be any
business logic in the objects. Almost all the objects which we identfy as business objects
may have methods like add, delete, update and retrieve methods. Still in these cases, is it required to
have business objects or can we use transfer object to send the data for saving and retriving or any other
pattern/guideline is there for dealing such cases?
I really appreciate your comments on this topic.
Also I apologize ahead of time if my explanation is not clear to you.



Thanks in advance.


Regards,


Rizwan.

   <<Less

Re: Is it mandatory to use Business object for data transfer and work flow?

Posted By:   Shaun_Childers  
Posted On:   Tuesday, August 30, 2005 09:42 AM

What it appears you are asking is: how can I design an application that separates the business logic from the data and/or is this the right approach?


Rizwan, you are thinking correctly - you should separate your business logic from your data objects that represent the data/state of your system at a particular instance. In other words, you want to create some "read-only" objects to hold your data and keep your applications business separated. This leads to a question for you: what is your overall architecture in terms of how you are modeling your business and persistence tiers?


If you are using:

- EJB: You should look at the data transfer object pattern. While not the most desirable solution, it works to allow the data to be sent to/from the beans back to the business layer.


- POJO's and persistence framework: Just keep the data as POJO objects, but don't think of this in terms of transfer objects, rather as just objects representing some entity in your system.



The main thing is to only design the simplist thing to satisfy your requirements, yet flexible enough to accomodate future changes.



Overall, what is your architecture in regards to deployment? If you are co-locating your business tier from your persistence tier, you will need to make your objects Serializable. Keep in mind how you are handling your data between the business and presentation tiers as well.

Re: Is it mandatory to use Business object for data transfer and work flow?

Posted By:   Anonymous  
Posted On:   Saturday, August 6, 2005 12:47 PM

Well.. the bottom line is to transfer data between separate layers, the good practice is to use a Value Object/Data Transfer Object. For example, if your business object has an EJB implementation, you do not pass the EJB reference back to the presentation layer of your app.. u use Value Object.



The methods you mention create/read/delete etc. are all business methods and are correctly placed within the business objects. However, you might need a more coarse grained interface and in that case you might use a Session facade. For example, if u have a method.. checkAndDeleteData() that will internally read and then delete the data but user does not need to invoke read() and then delete() method. You can have a session facade with a method called checkAndDelete()...



Anyway, ask me more if this is not clear. ...



By the way, thanks for a positive feedback on my article and nice to know readers like you found it useful



Thanks


Samudra
About | Sitemap | Contact