Customer Application Framework
(initial content; copied from toolpack guide) |
(added link to CAF category and associated articles) |
||
| Line 8: | Line 8: | ||
== The customization of CAF == | == The customization of CAF == | ||
Of course the framework will not address all of the clients needs perfectly. This is why most of the classes may be subclassed or re-implemented to provide a better fit and still be used in the rest of the framework. For example the data access object for a client account may be reimplemented to query a non supported database. This DAO could then be used in the gateway application with minor modifications. | Of course the framework will not address all of the clients needs perfectly. This is why most of the classes may be subclassed or re-implemented to provide a better fit and still be used in the rest of the framework. For example the data access object for a client account may be reimplemented to query a non supported database. This DAO could then be used in the gateway application with minor modifications. | ||
| + | |||
| + | |||
| + | ==References== | ||
| + | *[http://docs.telcobridges.com/mediawiki/index.php/Category:CAF Articles concerning CAF]. | ||
Revision as of 11:06, 22 October 2009
The Customer Application Framework (CAF) library comes in where the CMC library left off. The main purpose is to provide a set of optional C++ classes that may be used to easily implement gateway applications. The CAF classes build on CMC legs and provide easier management of calls, CLI, memory, logger, database, etc. CMC samples and applications are built on this framework since the code is easier to understand and the development time is shortened.
The optional nature of CAF
Clients should not need to integrate in a really big framework just to use one of the framework's helper classes. This is why each individual element of the framework is designed to be optional and independent. For example it is not mandatory to use a routing class to create a call class.
The customization of CAF
Of course the framework will not address all of the clients needs perfectly. This is why most of the classes may be subclassed or re-implemented to provide a better fit and still be used in the rest of the framework. For example the data access object for a client account may be reimplemented to query a non supported database. This DAO could then be used in the gateway application with minor modifications.
