IMHO, Microsoft chose a confusing name of the vast class library that comes with .NET when it called it a FRAMEWORK. To us VFP developers, a framework is a collection of classes, prgs, etc. that work TOGETHER to accomplish a set of commonly needed tasks related to database applications. Tasks such as screen handling (add, edit, delete, navigate), security, connection to a server, database maintenance, etc. The .NET framework is a collection of mostly unrelated classes that are primarily generic in nature and not meant to solve a specific type of application development problem. Not to diminish the .NET framework. A very powerful and useful library. But, why didn't they call it the .NET class library? It was largely ported from the MFC foundation class library anyway and this makes more sense to me. Ray Kirk
Ray, thanks for the eloquent description of what I've been trying to say all along. The .NET "framework" is not what I would consider a framework either, at least not in the "application building" domain. Another thing that *most* data centric frameworks provide is a data dictionary. I would miss this big time - of course, I could roll my own over time, but that's the beauty of a pre-built *framework*. -- Randy Jean
One more thing to add that seems to be missing from all of this discussion: RAD. One of the primary reasons I use a framework is not necessarily for best practice reasons. I also get *RAD* capabilities - So far, I don't consider VS.NET by itself anywhere close to a RAD environment, but again, I'm just learning... But to contrast, when I was just "learning" VFP, the framework we purchased greatly shielded me needing to know much about the language itself through the use of builders and wizards, etc. Maybe some would say this is the wrong way to learn, but it's proved very successful for myself and my clients -- Randy Jean
Is there a business case for why Microsoft would want to be in the Framework business? -- Steven Black
Definitive answer: http://www.eweek.com/article2/0,3959,462128,00.asp
Wow excellent pointer, thanks. BTW I've been there. It's not a tools issue. Anybody who tells you federation is a tools or infrastructure issue is kidding you. Federation Isnt About Tools Or Infrastructure -- Steven Black
Microsoft sells development tools so that applications are made that sell operating systems. Microsoft makes $$$ selling OSes. The DotNet "Framework" is a set of *foundation* *classes* (catchy name, that) that make it easier to write apps that will sell OSes. Microsoft does *NOT* want to be in the framework business, any more than they want to be in the application development, consulting or solutions business. Too much liability, too poor a ROI, no scalability. Microsoft Consulting Services is there to help the F-500 clients buy more OS licenses, but Microsoft farms out development to Solution Providers and "Partners."
I disagree with Randy in respect to the RAD issue. To me it seems easier to learn the Framework, get any third party tools if I need something specific, and just do it, rather than worry about carefully abstracting the Framework. It must just be a philosophical thing. -- Mike Helland
It's not philosophical, it's the way I learned how to program. I spent a few years in FoxBase learning from poorly written code done from scratch. When Foxpro 2 and CodeBook came along, I had an *awakening* of how much time I had wasted in the past with copy & paste, search and replace, whatever you want to call it. That was when I was an in-house developer and had the luxury of time. I decided then and there that I was going to try and learn and benefit from others mistakes instead of making my own and constantly re-inventing the wheel. This *philosophy* has served me well in the consulting world. I don't want to build frameworks (enhance them if needed, but not build from scratch). Let me ask you this: if the .NET framework were so complete, how come there is a VFP Toolkit that ports native VFP functions? Look at the code in some of those - it's taking many lines to perform what 1 line of VFP code can do. When I do start developing in .NET, why wouldn't I use these classes? Are they not an abstraction layer? Forget they mimic VFP behavior even, just realize how much coding time you are saving. Buy, borrow or steal vs. build is my real philosophy, I guess. -- Randy Jean
I completely agree, Randy. The old adage applies.
Good programmers write good code.
Great programmers steal great code.
Yep. And to clarify, I guess the VFP Toolkit doesn't really argue the *inheritance* or *framework* issues discussed, as it is more equivalent to a collection of user defined functions. But I guess the point I was trying to make is that I'll use anything that saves time (doing full quality control, of course) whether it be a full framework or a set of user-defined functions or components that encapsulate frequently used functionality. I don't by the *you only need this one tool* argument. -- Randy Jean
I don't recall anyone anywhere saying "You only need this one tool". -- Mike Helland
OK, then maybe I misunderstood the arguments being made in One Environment Versus Many Environments. But besides that, someone was also claiming that inheritance will be of little use in .NET - this is the point I'm really disagreeing with as I see inheritance as one of the most important features in .NET -- Randy Jean
My understanding is the Java folks chose to poorly name their library a "Framework" first. Then when Microsoft got on the bus they picked up the habit. Handy way to pull yourself up to the competition. Joe Kuhn
Category DotNet Category Frameworks
( Topic last updated: 2002.08.29 06:39:30 AM )