>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:
>

Now, see I like that idea. That would be the best reason to have to purchase a commercial framework. I would love it, to steal some ideas and just learn some different approaches.

>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.
>

I can understand that not everyone wants to be, and it may not be the best solution for all. If you only have a few developers, and no real experience then I could see it. But, I think eventually I would think that they would want to understand it, and perhaps at least at to it.

>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.
>

Yeah, flexiblity is very important. But that is where I run into problems with commerical frameworks, trying to be everything to every one. I see how MM tries to get around this, but it is impossible to satisfy everyone. And if you do you create your own, then you will be able to do it your way.

>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.
>

I agree, and we use business objects, but we are lucky to have a good framework designer.
>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!
>

Yeah, Rick is really sharp.

>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!

Yeah, it does help. After all of this "discussion" about commerical framework, I have at least a better understanding of why some people would want to purchase them. I hope you didn't think I was trying to take a stab at the MM.NET, I was just curious.

Morgan