ASP.NET "Whidbey" Provider Model

ASP.NET already has many great extensibility points: you can add new HttpModules to interact with an incoming or outgoing request, you can add your own HttpHandler to take over the processing of individual requests, you can extend the configuration system, and finally you can derive from many of our server controls to add your own specific behaviors. In ASP.NET “Whidbey” we're introducing a new extensiblity point: Providers.

The concept of a provider is something we initially started experimenting with in the ASP.NET Forums. The idea that the data layer of the application, for example all the code specific to SQL Server, would exist in a separate assembly that could be loaded by the running application. This allowed for developers to write their own data layers and simply plug it in (note, this first data layer abstraction concept was from Scott Mitchell). With ASP.NET “Whidbey” we're taking it to the next level. Many of the new features -- Membership, Personalization, Role Manager, Site Navigation, Build Providers, Health Monitoring, etc. -- now support a provider model. However, rather than being only a data layer abstraction the provider model in ASP.NET “Whidbey” is both a data and business logic layer abstraction.

What this means to ASP.NET developers is that you can completely unplug the logic/behavior/data interaction of a particular feature of ASP.NET and replace it with your own logic/data layer. A great example is the new Membership system for managing user credentials. Membership provides an easy way for you to validate a user's credentials:

bool Membership.ValidateUser(username, password);

Internally this call to ValidateUser is being forwarded to a configured provider. For example, the SQL Server Membership provider:

public class MembershipSqlProvider : MembershipProviderBase {

  override public bool ValidateUser (string username, string password) { ... }

}

The provider selection is determined by settings in the web.config (or defaults in the machine.config) file. Both the ASP.NET Forums and Dot Net Nuke projects already implement this new provider model -- in case you'd like to see examples of how this system works. Below is sample configuration data from the web.config of the ASP.NET Forums to configure a provider:

<forums defaultProvider="SqlForumsProvider" defaultLanguage="en-en" >

  <providers>

      <clear/>

      <add name = "SqlForumsProvider" 
           type = "AspNetForums.Data.SqlDataProvider, AspNetForums.SqlDataProvider" 
           connectionString = "[hidden]"
           databaseOwner = "dbo" />

      <add name = "AccessForumsProvider" 
           type = "AspNetForums.Data.AccessDataProvider, AspNetForums.AccessDataProvider" 
           fileLocation = "~\data\AccessDataProvider\AspNetForums.mdb" />

    </providers>

</forums>

The defaultProvider attribute in the <forums /> element instructs the forums application as to which provider (in the <providers /> section) is the default of the application. The <providers /> section is then used to add (or remove) providers that are available to the application. In the above example, the provider is 'SqlForumsProvider' (since we haven't completed the Access provider yet) and the application then loads and uses this provider for any data interactions.

As you can see, providers are very powerful new feature of ASP.NET. One of the huge wins for everyone is that there is no data model your are locked into. Yes, we'll provide a great data model for many of our features, but if you've already got a data model or use data from other sources -- such as an Oracle or DB2 database -- you can still easily integrate it with ASP.NET and take advantage of all of the API education we're putting in place for these features.

In fact, we're planning on writing some sample providers for both Oracle and DB2 that we'll post the source code for. If you'd like to learn more about the provider feature, check out the Membership and Role Management or Personalization talks from the PDC. You can access the powerpoints and demos at http://www.asp.net/whidbey/.

P.S., lots of people have been asking where they can get the ASP.NET “Whidbey” alpha from. Unfortunately the Alpha is limited to PDC attendees and MSDN Universal subscribers. If you're an MSDN Universal Subscriber, you should be able to call an order a copy of the “Whidbey” alpha.

Published Friday, November 07, 2003 9:07 AM by Rob Howard

Comments

# re: ASP.NET "Whidbey" Provider Model

Friday, November 07, 2003 10:22 AM by Thomas Tomiczek
A NEAT feature, indeed. How smart, Rob, is the caching architecture ABOVE the provider? I know this is a bad topic (actually), I am just ooking forward, and there area ton of negatives with caching above the provider.

While I love the model, though, just to let you know, I consider the providers and managment to be absolutly sub par from what I have seen. I have my own standard system for this already (which I will implement as provider, naturally), and we handle things like TIME LIMITED memberships to groups - something I found more than needed for websites. Someone has acces to some areas for one year, I want it to be ONE YEAR straight. Caching would step onto my toes here :-)

# re: ASP.NET "Whidbey" Provider Model

Friday, November 07, 2003 10:27 AM by Rob Howard
You've actually touched on the very point of why we have providers. We don't know what all the specific needs/behaviors, etc. will be. We wanted to give developers something that they could extend (or replace) with their own behaviors. So when you say 'Membership in a group for a year' that's not a problem at all. You could simply derive from our default and override methods to enforce that behavior -- same thing, for example, with enforcing a certain password format, locking the account after a certain number of failed logins, etc. ;)

As for caching. We currently do not cache anything at the provider layer (I assume you mean caching the data). We will be looking to integrate the new database caching functionality with some of our providers where it makes sense. That way we could intelligently cache data accessed through the provider and invalidate the data when the data in the database changes -- again all behaviors that you can change though.

# re: ASP.NET "Whidbey" Provider Model

Friday, November 07, 2003 10:51 AM by Thomas Tomiczek
::You've actually touched on the very point of
::why we have providers.

I know :-) Heck, I can hardly wait to install the DVD's that are on the way (my old alphas made "not too well" during a move) and put a secondary website onto it.

Terrific job.

::As for caching. We currently do not cache
::anything at the provider layer

Well, I dont care about the prvider layer, but about the layer ABOVE it. In need you to call into the provider on EVERY page :-) Well, maybe :-) My current membership system is pretty "optimal" in this way - we go into the Authenticated event and reuse an existent principal object (if it is still there AND still valid), otherwise we hit the business layer (means at least once every 5 minutes). I would not like any caching that makes people go into pages for which their right did expire 5 seconds ago :-) Yes, crazy, I know :-)

# re: ASP.NET "Whidbey" Provider Model

Friday, November 07, 2003 11:04 AM by Scott Watermasysk
I have also implemented a set of providers in .Text. See http://scottwater.com/blog/posts/10579.aspx

-Scott

# re: ASP.NET "Whidbey" Provider Model

Monday, November 10, 2003 7:15 AM by colin mcdonald
Not sure if this is in ASP.NET "Whidbey", but it would be nice if the "add" node had an optional attribute called "url" that referenced the URL of the provider which resided remotely.

Then, if you're using a Factory to instantiate your providers, you could get either a local provider or remote provider.

We're doing something like this at our company and this gives the ability to seperate our logical layers into tiers quite easily. .NET remoting is a wonderful thing ;-)

# Getting on the Provider bandwagon

Thursday, November 13, 2003 12:08 PM by TrackBack

# Provider Model vs. Proxy Pattern

Monday, December 29, 2003 11:57 PM by TrackBack

# Provider Model vs. Proxy Pattern

Monday, December 29, 2003 11:59 PM by TrackBack

# XML extensibility, xsi:type, XmlSerializer and configuration (or how to leverage XmlSerializer OO extensibility)

Friday, January 23, 2004 11:53 AM by TrackBack

# .NET framework and the Provider Model

Wednesday, February 04, 2004 8:21 PM by TrackBack

# re: ASP.NET "Whidbey" Provider Model

Friday, April 16, 2004 11:17 PM by Paul D. Murphy

This is a disastor waiting to happen. We you have an API that is funtionally wrapped up into a package a static methods (I know the Role Provider class isn't static, but it's access is) you have a service. The ASP.NET team should have built an infrastructure to make it easy to expose a clean API as a service. Read more here.

http://blogs.aspadvice.com/pmurphy/archive/2004/04/13/949.aspx

# re: Time to start coding on 'my' provider

Thursday, April 29, 2004 11:45 AM by TrackBack

# re: ASP.NET "Whidbey" Provider Model

Wednesday, June 30, 2004 12:26 PM by Paul D. Murphy
My solution to the provider problem is here.
http://blogs.aspadvice.com/pmurphy/archive/2004/06/30/1306.aspx

# re: ASP.NET "Whidbey" Provider Model

Sunday, July 25, 2004 11:33 AM by AD
http://homebiz.seolink.net

# re: ASP.NET "Whidbey" Provider Model

Saturday, July 31, 2004 11:28 AM by 注册公å&#18

http://www.banzhao.com/
http://www.banzhao.com/gongshang/wzlct.htm
http://www.banzhao.com/gongshang/gs.htm
http://www.banzhao.com/shuiwu/sw.htm
http://www.banzhao.com/bbs/index.asp
http://www.banzhao.com/gongshang/neizi/nianjian.htm
http://www.banzhao.com/shuiwu/kuaijifw/zzs.htm
http://www.banzhao.com/shuiwu/banshuizn/fapiaorg.htm
http://www.banzhao.com/shenpi/sp.htm
http://www.banzhao.com/shenpi/icp.htm
http://www.banzhao.com/shenpi/gaoxin.htm
http://www.banzhao.com/shenpi/rj.htm
http://www.banzhao.com/bbs/Boards.asp?Assort=1
http://www.banzhao.com/bbs/Board/Board.asp?BoardID=101
http://211.147.117.100/
http://www.banzhao.com/gongshang/neizi/mingchengyh.htm
http://www.banzhao.com/gongshang/neizi/gs2.htm
http://www.banzhao.com/gongshang/neizi/biangeng.htm#
http://www.banzhao.com/gongshang/neizi/yinhangkh.htm
http://www.banzhao.com/shuiwu/banshuizn/dishuidj.htm
http://www.banzhao.com/shuiwu/banshuizn/guoshuidj.htm
http://www.banzhao.com/gongshang/neizi/biangeng.htm
http://www.banzhao.com/gongshang/neizi/chanquan.htm
http://www.banzhao.com/gongshang/neizi/slfgs.htm
http://www.banzhao.com/gongshang/gsxz.htm
http://www.banzhao.com/liuyanban/index.asp
http://www.banzhao.com/gongshang/neizi/zijinrht.htm
http://www.banzhao.com/shuiwu/kuaijifw/wsfw.htm
http://www.banzhao.com/gongshang/neizi/zhangcheng.htm
http://www.banzhao.com/gongshang/neizi/zhuxiao.htm
http://www.banzhao.com/gongshang/neizi/farendm.htm
http://www.banzhao.com/shenpi/315ba.htm
http://www.banzhao.com/shenpi/rjqy.htm
http://www.banzhao.com/gongshang/waizi/slsp.htm
http://www.banzhao.com/shenpi/gg.htm
http://www.banzhao.com/shenpi/sp2/fdcjj.htm
http://www.banzhao.com/bbs/Announce/Announce.asp?BoardID=101&ID=240
http://www.banzhao.com/bbs/Announce/Announce.asp?BoardID=101&ID=269
http://www.banzhao.com/bbs/Announce/Announce.asp?BoardID=101&ID=278
http://www.banzhao.com/bbs/Board/Board.asp?BoardID=94
http://www.banzhao.com/bbs/Board/Board.asp?BoardID=98
http://www.banzhao.com/bbs/Announce/Announce.asp?BoardID=100&ID=213
http://www.banzhao.com/bbs/Board/Board.asp?BoardID=100
http://www.banzhao.com/bbs/Announce/Announce.asp?BoardID=96&ID=102
http://www.banzhao.com/bbs/Board/Board.asp?BoardID=96
http://www.banzhao.com/bbs/Announce/Announce.asp?BoardID=87&ID=142
http://www.banzhao.com/bbs/Board/Board.asp?BoardID=87
http://www.banzhao.com/bbs/Board/Board.asp?BoardID=97
http://www.banzhao.com/bbs/Boards.asp
http://www.banzhao.com/guanyu.htm
http://www.banzhao.com/fuwu.htm
http://www.banzhao.com/gg.htm
http://www.banzhao.com/xiezilou/index.asp
http://www.banzhao.com/banquan.htm
http://www.banzhao.com/tongji/supervise/index.asp?uid=wangdi

# re: ASP.NET "Whidbey" Provider Model

Saturday, July 31, 2004 11:29 AM by 注å&#
[[http://www.banzhao.com/ ????]]
[[http://www.http://www.banzhao.com/gongshang/gs.htm/ ????]]
[[http://www.8z.cn/ ????]]
[[http://www.gongshangzhuce.com/ ????]]
[[http://www.banzhao.com/gongshang/waizi/slwz.htm/ ????]]
[[http://www.banzhao.com/shuiwu/sw.htm/ ????]]
[[http://www.icp315.com/ ????]]

# re: ASP.NET "Whidbey" Provider Model

Saturday, July 31, 2004 12:07 PM by dmoznet


[[http://www.3721blog.com 1.3721blog]]
[[http://www.sohublog.com 2.sohublog]]
[[http://www.baidublog.com 3.baidublog]]
[[http://www.yisounet.net 4.yisounet.net]]
[[http://www.yisounet.com 5.yisounet.com]]
[[http://www.dmoznet.com 6.dmoznet.com]]
[[http://www.dmoznet.net 7.dmoznet.net]]
[[http://www.dmoznet.org 8.dmoznet.org]]
[[http://www.myricenet.com 9.myricenet]]
[[http://www.amoyplastic.com 10.amoyplastic]]
[[http://www.alexanet.com 11.alexanet]]

# re: ASP.NET "Whidbey" Provider Model

Saturday, July 31, 2004 12:08 PM by dmoznet


[[http://www.3721blog.com 1.3721blog]]
[[http://www.sohublog.com 2.sohublog]]
[[http://www.baidublog.com 3.baidublog]]
[[http://www.yisounet.net 4.yisounet.net]]
[[http://www.yisounet.com 5.yisounet.com]]
[[http://www.dmoznet.com 6.dmoznet.com]]
[[http://www.dmoznet.net 7.dmoznet.net]]
[[http://www.dmoznet.org 8.dmoznet.org]]
[[http://www.myricenet.com 9.myricenet]]
[[http://www.amoyplastic.com 10.amoyplastic]]
[[http://www.alexanet.com 11.alexanet]]

# re: ASP.NET "Whidbey" Provider Model

Friday, December 01, 2006 12:14 PM by Arnout

Seems to me a perfect way to make a difference in the layers.

Something what bothers me though is that eg the logincontrol does not work with overloaded functions in custom Membership.

eg ValidateUser with an extra parameter does not work.

And this makes it all less transparent..

Arnout