Hello John,

I think there are a few areas you need to consider when looking at a framework:

1. Overall design

We've been using Mere Mortals since 1998 and I cut my OOP teeth on it. I've always been impressed with how well thought out it is, especially how multi-tier OOP principles were incorporated without sacrificing the native data access speed of VFP.


2. Flexibility/Customization

Business objects, rules objects, event objects, data access objects, and the various system managers (form manager, dbc manager, error manager, etc.) are the core components of Mere Mortals. The design is heavily reliant upon the (data driven) Abstract Factory design pattern to achieve maximum flexibility for your customization needs... again without sacrificing speed.


3. Support

Most of MM's support is handled here on the UT. This forum is checked regularly by many of us, including Kevin, and "situations" are resolved as quickly as possible.


4. Ease of use/Quick productivity/Training

Pardon me for lumping these together, but I think they're all related. As with any framework, there is an adjustment period, in which users need to understand where the architect was headed with the design. Otherwise, you'll find yourself fighting the framework. Unless everyone on your design team is a visual learner, they'll eventually have questions that are best answered in a classroom setting.

The best way to do this is to take one of Kevin's training classes. You will not only get hands-on experience, you'll also gain valuable insight into the Mere Mortals design and what is has to offer you... plus the added bonus of getting to meet Kevin! Which brings me to #5


5. Chief Architect

I don't know how many chief architects/"top-level" programmers you've met or how long you've been a member of the UT, but there aren't many at Kevin's level who -- how can I put this delicately? -- share his temperament! He's an excellent teacher because he's down to earth and not above explaining basic concepts when necessary. Kevin's also very easy to talk to, and amenable to framework change requests. I think he also likes long walks on the beach at sunset, but that's another thread entirely.


6. DTA

As in "Don't Trust Anyone!" Take the time to examine as many frameworks for yourself as possible. Make sure you find the right fit for your company. I've likened this process to hiring an employee. A highly integrated employee upon which your entire project will depend. You don't want to find out in 6 months that your framework is a bad fit, sucking your productivity and morale, Charybdis-like, into a maelstrom of despair and bitterness.

Hope that helped,
---J

>Hi,
>I am considering to get framework to help my development. Could anybody comment this framework since you are the one who really USE it?
>
>Thank you