ShowUsYour<Blog>

Irregular expressions regularly

Whidbey: a roll-up of some of my thoughts to date...

Ok, I've been doing quite a bit more playing with the Roles and Membership side of ASP.NET V2 with the December CTP release and, I think that I'm starting to get a better picture of its intended use.

In the past 2 weeks I've managed to look - at a fairly low level - at several of the major components of the next version of ASP.NET and I'm starting to form some opinions.

I think that the PortalFramework is going to be the big winner in ASP.NET V2.  Web parts seems to be a very extensive system which provides extensibility points at nearly every feature.

I believe that Membership is the most enigmatic of all the new features - with the possible exception of the UrlMapping stuff which I believe to be a lame duck. 

For me the main thing about Membership is that you will nearly always want to customize and extend it in some way.  Because of this, it is confusing in coming up with how "best" to extend an existing Member or Roles.  I'm sure that Membership is something that I'll come to love but, presently it just kinda grinds against me a bit, especially seeing as how I still have to do casts to get my custom Membership object back at page level.

I think that the stuff about using an IsOnline flag could have been left off of the base membership object model and just shows that they used a forums model when they developed it.

If there's anybody out in blog-land who has played around with Membership much and would like to compare some notes, please contact me via my blog as I have reams of things that I'm keen to work through with somebody.

Posted: Feb 05 2005, 06:24 PM by digory | with 5 comment(s)
Filed under:

Comments

Paul Glavich said:

Hi Darren,

Interesting to hear your thoughts. I must admist, the UrlMapping doesn't interest me much at all.

I think the Membership features are good, but like yourself, they will probably languish initially (IMHO) until people get a good handle on how best to use it in their scenario, particuarly in the enterprise where the current situation probably works well for most cases. However, once a suitable cusotmisation is done for your particular organisation or scenario, then I think ist benefits will become much more obvious and therefore prevalent.

Note: I haven't had a play with the Dec CTP yet, its all based on the previous builds. So many VPC images, so little time.... ;-)
# February 5, 2005 6:06 AM

Darren said:

Yes Darren, you should note the December CTP is a fair bit older in terms of ASP.NET than the November CTP. That is because the December CTP was produced by the team working on Team System, and they had not merged back with the main branch (which will happen around Beta 2 time).

So if you really want to be checking out these API's the November CTP is the more recent one you should be using.

Also, they have the new app_code, app_data (etc) directory structure, plus the modified Partial Class system working in the November CTP (and I think the December CTP is still using the older system used for Beta 1).

David Taylor
# February 5, 2005 8:05 PM

Darren Neimke said:

Hi David, yes, I've actually played with the NovCTP stuff too. I went back to the DecCTP because more people seemed to be running it and, therefore, more people could consume my samples and give me feedback. The actual API's for Membership and Portal haven't really changed that much between the Dec and Nov CTP's only a bit of syntax here and there.

I don't want to come across as being negative against Membership. In fact, that's exactly why I chose the word "enigmatic" in my description of it.

All that I'm trying to say is that, I think that, on the surface, Membership looks easy and cool but when you dig in under the covers and start implementing it, it's less obvious.

For example, I'm also interested to see when it's best to inherit from the existing membership providers and when to roll your own. I'm lazy, so, I'll be inclined to inherit whenever possible but to get the full benefit out of the model though, you really need to roll your own.

... so, then it becomes interesting as to "why" they locked you into so many things when you have to roll your own anyways and yet you still don't get strongly typed access to your custom Member at runtime.

I also think that Paul's comment (the first one in this thread) has some great points, in particular:

<quote>
However, once a suitable cusotmisation is done for your particular organisation or scenario, then I think ist benefits will become much more obvious and therefore prevalent.
</quote>

So now it just becomes a matter of finding that ideal implementation model and that's what I'm trying to do by opening it up for discussion.









# February 5, 2005 8:26 PM

Darren said:

Well they have tried to achieve the almost impossible right.... This is a very hard API to design given everyone already has their own internal API to do auth.

And why have they done it? And why do they lock you down the way they do? ... The reason is so you have have out-of-the-box controls (like the Login control, etc) plus out of the box management apps (like the web configuration app) that can ideally handle all the variations supported by the API and controls, and provide "free" ui and management interfaces.

About 6 months ago I implemented the API for one of our own internal systems, and it was quite a bug using the new ASP.NET config tool to add and search users in my backend system :-) One thing I would have have needed to write myself.

Personally....I am just excited by the concept of getting a 3rd party product written for V2.0, and just *plugging* it in to my own system
# February 7, 2005 5:01 PM

Darren Neimke said:

Darren (if that's your name)... I agree that Membership is a good thing so, I hope that you don't think that I'm trying to say that it's bad. There are many reason why it rocks that they took the step to implement a single point of entry for application Membership which I'll blog about later. All that I was trying to say is that getting the usage right can be more complicated than you'd imagine from first looking at it.
# February 7, 2005 5:16 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)