Why a Framework for a Framework?

"Why do I need another framework such as MM .NET if I've already got the .NET Framework?"

To answer this question, you must first understand "What is the .NET Framework?" The .NET Framework is two things:

The Common Language Runtime (CLR) which manages the execution of .NET programs including memory management, garbage collection, exception handling, and assuring type safety.
The .NET Base Class Libraries (BCL) which is comprised of thousands of classes including user interface classes and other core classes that provide object-oriented access to the services of the underlying operating system.

Building an application directly from the .NET base classes without an application framework is like being given huge piles of construction materials and being asked to build a house. Everything you need is there, but you don't know where to begin.

In contrast, MM .NET provides a basic foundation and structure on which to build your applications. A big part of this is higher-level objects that provide services for your applications, such as:

Business components
Database management
Intelligent Data binding
Security
Localization
Exception Handling and logging

None of these are out-of-the-box components in .NET, although they are services most applications need. Rather than recreating these services each time you create a new application, you need a framework that provides these components that can be reused in your Windows Forms, Web Forms, Web Service, and Smart Device applications.

Architectural Guidance

Are you painting yourself into a corner? How do you build a well-designed, flexible, and scaleable application in .NET? Using the basic project templates in Visual Studio is not going to get you there. For example, when you create a new Windows Forms application in .NET, the new project the only thing you get is an empty form, a program file, and assembly information file as shown here:

When a developer creates their first .NET application and sees this, the usual reaction is "Now what?"

In contrast, we've created templates for MM .NET applications that take you much further along the curve, and provide design guidance. For example, when you build a new MM .NET Windows Application, it asks if you want to create a new business object project. If you reply "yes", it adds a new business object project to your solution as shown here:

Mindshare - The Benefit of "Open Source"

One of the greatest benefits to using a commercial framework rather than a homegrown one is the mindshare created by many developers using the framework to create a wide variety of applications. The framework is tested, stretched, extended, and enhanced in ways that an internal framework built by an individual company can never achieve.

We have been fortunate to have many high level developers use our MM .NET Frameworks, and they have added tremendous value to MM .NET with great new ideas, bug fixes, and enhancements.

Since we provide source code with MM .NET, developers can easily see what's going on behind the scenes. This approach has been a tremendous benefit to us and our users, similar to what is achieved with open source languages and tools. For example, when a developer has framework source code it's much easier for them to determine how best to override a particular method because they can see for themselves what's going on behind the scenes.

Design Patterns - "Doing it Right"

Choosing an application framework is very much like choosing a marriage partner. This is also true of homegrown frameworks. We have worked with a number of companies who have had bad experiences pulling themselves out from under a framework built in-house by well-meaning developers who had little framework design experience.

So how can you know if the framework you are choosing will result in a happy, productive relationship, or one filled with regret? Although it's not a silver bullet, the use of standard object-oriented design patterns is a great step in the right direction.

Design patterns provide both developers with proven solutions to object-oriented problems. For example, one of the biggest complaints developers have against frameworks is they force you to do things a particular way. However, if a framework architect subscribes to the guideline of "programming to an interface rather than an implementation", it allows developers to easily change the framework that suit their needs.

When adding features to MM .NET, we always think "someone isn't going to want to do it this way", and we always provide a way for developers to change or extend how we've implemented a feature.