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

[Johnty Rhodes]

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]

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]

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]

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]

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]

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!