• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

To bean or not to bean

 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I don't know if this is the right place to ask my question, but here it goes.
I'm building a small Swing application that retrieves a list of companies from a db, and will allow the user to add, modify and delete. Since I'm learning Java with this project, there are a few things that I don't know what I should do. Everything works so far, but I know the design could be better, so I'm trying to improve my code.
I used MVC to build my app, and the central class in this application is the Company class (it's also the Model). Since it has getters/setters and seems to be doing a bean's job, should I make it serialized so that it's a real bean? If so, why?
Also, I have a few functions in that Company class that get data from my db. Is this the correct place to put my queries in? Should I create a separate class for my db transactions?
I would be very appreciate for any valid suggestions.
Thanks in advance,
Marie
 
Author
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Marie Mazerolle:
Hi,
I don't know if this is the right place to ask my question, but here it goes.
<snip>
I used MVC to build my app, and the central class in this application is the Company class (it's also the Model). Since it has getters/setters and seems to be doing a bean's job, should I make it serialized so that it's a real bean? If so, why?


Hi Marie,
A good question to ask yourself is "what are the requirements of my app (functional and non-functional)" and let these answers drive your architecture and design.
As for serializing your object, do you need to transfer information across a physically distributed boundary? ie: is your biz tier remote from your presentation tier? This is one reason you would want to serialize an object...so that you can use it to transfer data across this distribution boundary to reduce the sort of network performance problems that can arise with distributed object invocations. This pattern is called "Transfer Object" and is typically used in J2EE when you are using EJB in a remote biz tier. In this case, you would use a remote Service Facade, called a "Session Facade" to serve as a uniform, course-grained access point into your remote services.
If you do not have a remote business tier, you can still use EJB, using Local Session Beans as your Service Facade for the same purpose. Using Session beans in this way gives you the benefit of using their transaction semantics and declarative security. If you don't need these features, then you can use a Plain Old Java Object (POJO) Service Facade, foregoing the use of EJB entirely. Lots of different options.
Either way, your Service Facade should delegate to Application Service(s) (another pattern), where your common service code resides. Application Services work with Business Objects, which represent your domain model (such as Company in your case).


Also, I have a few functions in that Company class that get data from my db. Is this the correct place to put my queries in? Should I create a separate class for my db transactions?


There are numerous approaches to persistence. Separating your data access logic from your Business Object and moving it into a separate class as you suggest is described in the "Data Access Object" (DAO) pattern. There are many other options, as well.
We cover all this information in detail, including design tradeoffs and code samples in our book Core J2EE Patterns, 2nd ed.
We're hanging out over in the "EJB and other J2EE" forum this week, so you may want to ask some questions in that forum as well.


I would be very appreciate for any valid suggestions.
Thanks in advance,
Marie


Remember, use patterns as a guide and use what works, but don't feel compelled to use a pattern "just because it's there".
A pattern is a tool, just like any other and should be used judiciously and appropriately.
Hope this helps.
 
Marie Mazerolle
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wow, thanks for the comprehensive answer, Dan! I'll definitely have a look at your book.
Marie
 
reply
    Bookmark Topic Watch Topic
  • New Topic