| Home | Previous Lesson: Disadvantages Next Lesson: Three strategies for extending PFC to multiple departments |
Strategy #3 is best architecture of all the strategy's and provides a high amount of flexibility. This strategy is recommended for the following reasons:
Strategy #2 is not recommended due to the fact that methods and attributes added will not be available to existing PFC services.
Strategy #1, while very similar to Strategy 3, does not allow meaningful object naming standards at the application/departmental level simple because the application/departmental level is the PFE level. It also it mixes framework code with the application specific code which is not good. In this strategy, a sub-departmental extension level cannot be added between the department level and PFE.
Strategy #3, while similar to strategy 1, provides the flexibility of having meaningful object names for each department and it is easier to escalate and promote objects to the corporate level from various application/departmental levels because the application/departmental level objects can have meaningful application/department-specific names. It allows the flexibility of adding either pre or sub departmental levels if needed.
| Home | Previous Lesson: Disadvantages Next Lesson: Three strategies for extending PFC to multiple departments |