Morgan,

I've read through all the messages in this thread so far (late Wednesday night) and it looks like you've created quite a stir!

I know you folks (including Bonnie and Gary) have already written your own in-house framework, and based on your posts it sounds like it was a good decision for you. I understand your basic objections to frameworks, because I have some of the same problems with them...but I think there are several valid reasons for using a GOOD commercial framework. Here are some of the reasons people have purchased MM .NET:

1. They can steal ideas from it. This is the lowest level at which developers use our framework. Occasionally I run across developers like yourself who simply feel it's best to write their own framework. However, they don't want to figure everything out for themselves, or they want to study different approaches. I've done my homework with .NET, and people know it. Two years ago, I sat down with an early copy of the .NET Framework and created UML class diagrams including each class in the framework and I read through all of the .NET Library documentation. This helped me get a good grasp on the .NET base class library and allowed me to discover the "holes" in .NET. Most people don't have the time or patience for this. I pass along much of this information in our documentation and in our source code comments.

2. Not everyone is a framework developer, or wants to be. Framework-level development is difficult...period. It requires a solid grasp of design patterns in multiple levels of abstraction. One of my main goals with MM .NET is to teach developers good architectural principles. I demonstrate use of patterns at the framework level that can be used by developers in their applications. Over and over again, MM .NET demonstrates the principle of "programming to an interface rather than an implementation" and provides solid examples of how this can be implemented, as well as the implementation of many different design patterns.

That said, I strongly agree that developers should know what's going on behind the scenes, and not simply rely on their knowlege of a framework. Based on this, in my .NET classes, I teach all of the "under the hood" information about MM .NET and the .NET Framework. For example, although you can use MM .NET with very little knowledge of ADO.NET, we cover ADO.NET in detail during class.

In our classes, I also teach a lot about good software architecture. I'm an educator at heart and in MM .NET I provide lots of "more than most people want to know" information about how things work behind the scenes, including UML class and sequence diagrams. Many developers are aware of design pattern basics, but are not sure how to best implement these in their applications. In MM .NET, we endeavor to show them. For example, when architecting our "automatic" data binding in Windows Forms and Web Forms, we used a model-view-controller design pattern, which provides loose coupling between the business objects and user interface controls. When I speak at both VFP and .NET user groups, this approach makes perfect sense to most developers in the audience, but I can tell you the vast majority of developers have either never heard of this pattern, or never used it before.

3. MM .NET is built from the ground up with flexibility in mind. I personally despise being forced to do things a particular way. So, whenever I'm designing a framework feature, I always remind myself that "someone will not want to do it this way". So, I use standard design patterns, factories, factory methods, abstract classes, interfaces, hooks, and so on, to make it easy to alter framework behavior.

Obviously, there are certain higher level philosophies you need to buy into when using a framework. For MM .NET, one of these is the use of business objects. Although you *could* create an MM .NET application without ever using a business object, the Framework is designed from the ground up with the supposition that you will. However, I've spoken at numerous user groups...including several .NET-specific user groups, and I can tell you the majority of developers in the audience have not come within ten feet of a business object! I think this is a huge mistake, and so it's one of the main themes I weave into every conference / user group presentation I give. I even co-authored a book "Professional UML with Visual Studio .NET" where I wrote the chapter on business components and got to stand on a nice, big soap box <g>. I've included similar information in our MM .NET Developer's Guide to build the case for using business objects in .NET applications.

4. The MM .NET Developer's Community. As mentioned elsewhere in this thread, one of the greatest features of MM .NET is the fact that many other developers are using it, testing it, extending, and enhancing it. WOULD that I came up with all the good ideas <bg>. We have lots of high-level developers using/working on MM .NET, which continues to advance it in ways that a single shop with their own private framework never could. Talk about code review!

Rick Strahl (who is also a Microsoft C# MVP) is now collaborating with us on MM .NET, and brings a tremendous amount of Web experience to the table with him. MM .NET has and will continue to get new features that reflect this.

Hope this helps!