ASP.NET 2.0 "plug-ins" say that
among the new features of ASP.NET 2.0, the most "dazzling" ones are master pages, themes/skins,
Membership and role management, user-defined attributes, and page personalization for WebParts.
Except for the first two items, the rest are based on the services provided by ***Provider.
These Provider (classes) are generally defined in Microsoft documents as follows: providing... services for...,
It seems to be the same as general control classes, etc., just use it. In fact, these Provider (classes)
It has very strongly hinted at a development direction of Microsoft .NET.
This direction is to "plug-in" the application (your website).
"Plug-in" is borrowed by the little brother to explain the problem visually. It is not necessarily precise and strict and is different from the concept of "plug-in" in Microsoft documents.
Let me briefly explain the reason why it is called a "plug-in" from both the software and hardware perspectives:
From a hardware perspective: If you imagine a PC, can web.config be regarded as a "motherboard"?
These providers are the graphics cards, sound cards, network cards... that are plugged into the motherboard. More abstractly, it can be considered that these Providers are actually equivalent to drivers. Microsoft provides us with Microsoft-branded
SqlMembershipProvider, SqlRoleProvider, SqlProfileProvider, SqlPersonalizationProvider
Provider also allows us to replace them by re-specifying them in web.config (equivalent to setting CMOS or doing "jumpers").
This is just like no matter what brand or model of graphics card (or sound card, network card, etc.), as long as it meets the compatibility standards, it can be plugged into the motherboard for use.
Thinking from a software perspective: Since the launch of Eclips, "plug-ins" on the development platform have also become popular (they have been available in browsers for a long time).
For a while, Java programmers were writing "plug-ins".
On the .NET side, because there is VS.NET, the impact is not very big, but we also use the "plug-ins".
I wonder if you brothers have noticed that VSS is integrated with VS.NET in the form of a "plug-in".
A purer example is Borland Togather for .NET. From these "plug-ins" integrated into the IDE, we can see that the "plug-ins" provide a kind of functional expansion and upgrade/replacement. Now relying on these Providers,
The website programs we develop ourselves can also be "plug-ins". For example: If we do not need the page personalization (WebPart) function, we do not need to "install" PersonalizationProvider
(In fact, it should be said the other way around, what functions are needed to "install" which Provider, but now they are all pre-installed).
So in the future, application development will be like installing machines in the computer market, just assemble and install them?
The answer is yes: Microsoft played with it like this when showing off its VSTS (Visual Studio Team System) product.
You can assemble a website without writing a single line of code, and the performance/stress test results are not bad (of course, it doesn’t just use “plug-ins”, it probably has to be called a component anyway).
It’s really more MAD than MDA (just kidding)!
The answer is also negative: In my opinion, this is a laboratory product after all. Microsoft engineers performed a "magic" under ideal conditions. On the one hand, we are not as professional as Microsoft engineers, on the other hand, every application has its own limitations. Special business needs, to put it bluntly, do not necessarily apply. In addition, the Sql series providers provided by Microsoft are all implemented according to a two-layer architecture, which is difficult to integrate into today's popular multi-layer architecture. For this reason, Microsoft has
http://msdn.microsoft.com/asp.net/downloads/providers/default.aspx?pull=/library/en-us/dnaspp/html/asp2prvdr01.asp
The sample code downloads of these Providers are provided so that we can split them into multi-layer implementations.
to be continued...
http://www.cnblogs.com/windman/archive/2006/09/20/509590.html