• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Part II - Need to document pros/cons of each design decision?

 
Johnty Rhodes
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do we need to document the general pros/cons of each design decision?

For example:
1. Why did we choose CMP/BMP?
2. Why did we choose adapter pattern?

Thanks
 
Samuel Pessorrusso
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure if this is needed, but I'm going to explain everything (my docs already has 10 pages [printed HTML]).

Regards
 
James Turner
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure if explaining why we use each design pattern is necessary, I have specified what patterns I have used, but not explained the details as to why.
 
Santiago Urrizola
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. Why did we choose CMP/BMP?

yes i think you MUST justify this types of desitions.

2. Why did we choose adapter pattern?


may by explain the benefits to use each patterns is enough
 
Yilmaz Oztanir
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You don't need to describe the pros *and* cons of every pattern, just why each one helps your system. However, for major things like frameworks you may want to say why you picked one framework over another.
 
Ricardo Ferreira
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

You don't need to justify every single pros and cons for the design patterns used at your assignment. Instead, you must to focus on meet the design decisions with the measured application.

For example, if you identify that the system must be able to change the database system without any impacts at the business tier, than you could (should) comment this at your documentation and show how did you fit this feature with some pattern or approach, maybe talking about how the Data Access Object (DAO) used in the design helped on that.

Another example could be an identification that the desired system must present some 'extra higher performance'. You could document that you have used the following patterns:

- ServiceLocator (Since every next lookup is replaced for an local cache of the Remote EJB handle)
- ValueListHandler (Since pagination is essential to the application, and are maintained at the EJB layer that manages the system growing)
- ValueObject (Since they reduce the overhead of too many remote method calls between the web tier to the ejb tier)

Anyway, you should fit your used patterns with the identified non functinal requirements of the application. Don't use a pattern just because every programmer uses or they can show that you know about them. If you attempt to use the BusinessDelegate pattern when it's not essential decouple the client tier with the ejb tier, or it's not essential wrap the remote exceptions at the client/web application, this is considered 'over-gluttering' the design, and YES, it is considered wrong!

Best Regards!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic