hiya,

I am wading thru an asp.net 2.0 eCommerce starter kit, which makes heavy use of "providers". In adition, it touts them as a flexible approach.

I was wondering, does llblGenPro make "providers" redundant? Has anyone in the "llblGenPro know" had a look at this kit and been immediately struck by how llblGenPro could reduce the codeBase? If so, any chance you could spare a few words?

I know this is slanted towards an MS starterKit, but it'd be an opportunity to discuss how an llbGenPro approach compares to the latest MS offering.

(maybe this post belongs in general section, I'm not sure)

cheers, yogi

yogiberr wrote:

I was wondering, does llblGenPro make "providers" redundant?

No. Actually, "provider" isn't anything new, it is just the name MS gave to a pattern that it saw being used and adopted it for various services in the framework.

Now, you can create providers that leverage LLBLGen if you want. But that doesn't make providers redundent.

yogiberr wrote:

Has anyone in the "llblGenPro know" had a look at this kit and been immediately struck by how llblGenPro could reduce the codeBase? If so, any chance you could spare a few words?

I don't think LLBLGen would "reduce" the codebase if you considered all the code the LLBLGen generates. It is a code generator after all. Also, most of the starter kits make use of datasets and/or the SQLDataSource which is a direct connection to SQL. While it requires very little code, it really isn't enterprise level n-tier architecture either.

BOb

Now, you can create providers that leverage LLBLGen if you want. But that doesn't make providers redundent.

righto Bob, I now see that I could swap the llblgenPro for the ms DAAB references.

I don't think LLBLGen would "reduce" the codebase if you considered all the code the LLBLGen generates. It is a code generator after all.

heh heh, you're right of course, I meant to say reduce the amount of code that I had to manually write.

As far as I can see though LLBLGen, would take away the hassle of having to bother with dataAccess providers....simply point LLBLGen to the correct database and it does the rest?

Ta for the reply, yogi

Aren't asp.net providers some sort of runtime code generators? (I haven't read up, as you might notice )

Otis wrote:

Aren't asp.net providers some sort of runtime code generators? (I haven't read up, as you might notice )

No.. the providers allow you to plug in different functionality and not break the existing application. For example, the built in asp.net login control, by default, looks up user information in a table in your SQL database called aspnet_users. What you can do is create a new provider (aka, a class that implements the membership provider interface). This new provider could instead access an Oracle database with a table called "Users".. All you have to do to force the login control to use the new provider is make some simple changes in your web.config. You don't have to recompile the app or anything. The provider model uses reflection to instantiate types based on the information in the web.config.

I hope that makes sense..

alexdresko wrote:

I hope that makes sense..

Perfect description. I couldn't have explained it any better.

BOb

alexdresko wrote:

Otis wrote:

Aren't asp.net providers some sort of runtime code generators? (I haven't read up, as you might notice )

No.. the providers allow you to plug in different functionality and not break the existing application. For example, the built in asp.net login control, by default, looks up user information in a table in your SQL database called aspnet_users. What you can do is create a new provider (aka, a class that implements the membership provider interface). This new provider could instead access an Oracle database with a table called "Users".. All you have to do to force the login control to use the new provider is make some simple changes in your web.config. You don't have to recompile the app or anything. The provider model uses reflection to instantiate types based on the information in the web.config. I hope that makes sense..

ah thanks.

Though I don't see the gain, the advantage: it's just a move of where the complex stuff is defined: instead of a code behind file, it's moved to a code file in app_bin or somewhere else, all for the sake of being able to do 'declarative' programming.

take for example datasourcecontrol based controls. You can free your code behind code from glue code to setup binding. But it's not gone, it's just moved to another place and not less complex also, it's more complex. The gain? A person who can't program is now able to setup the control. Though is this reality? I dare people to challenge me in this. Especially if you see the pile of docs to explain all the code you have to write to get things to work (and the uselessness of some of them)

Don't underestimate this. The complexity developers are now faced with isn't small, and won't be helped either by the fact that MS didn't released documentation to get a lot of things done easily.

Add to that the shift in paradigm when you go from BL to PL, and I think a lot of developers don't really know what to do. I'm for example seriously confused. I know how it should work though I seriously dont understand why this was all necessary, because the complexity isn't lower, on the contrary, it's just moved to a different place, and if you're the guy who has to deal with that different place, you're not going to be happy. Also, teams who have written asp.net sites in .net 1.x, will be faced with a dillema: what will everyone do? They now have to do 2 things instead of one: first write the classes, then the declarations to use them, but they're not in the same project, they've to go back and forth.

Perhaps I'm sceptical, but I don't see the advantage for now. Ok, I do see how a non-technical webdesigner now suddenly can build webpages, but I think the tools are now simply too crappy to make it possible. They need this shift of course for WinFX, which is build on this concept, but the tools for WinFX will be better than we have now, (special editors for presentation work).

I mean: today shifting from html to design will re-initialize all controls and vice versa. Tiny details you have to live with when writing the code which does all the work behind the declaration. Was it enough to write some little glue code to get controls to do what you want in .net 1x, you've to do much more now (IMHO) in some areas in .net 2.0, unless you want to use what's offered to you.

But perhaps I don't get all this declarative programming hype, as I've been frustrated for days now by the lack of serious docs on datasourcecontrol based controls, designers and what to do WHEN and WHERE, while this system they created is meant to be extended by developers.

Otis wrote:

Though I don't see the gain, the advantage: it's just a move of where the complex stuff is defined: instead of a code behind file, it's moved to a code file in app_bin or somewhere else, all for the sake of being able to do 'declarative' programming.

Provider pattern is not about declarative programming. It is about being able to extend or replace the implementation of built in ASP.Net functionality while still being able to use the .Net provided API.

One example is the Membership provider. ASP.Net's membership provider is an implementation of a security system that most people were writting themselves in ASP.Net 1.x. It provides a method to check a users credentials. It has methods to add a user, add roles to a user, delete a user, etc.

Since there is an established API they are able to provide controls such as the Login control, LogedinUser control, Change Password control that talk to the membership API.

Now, what if you want to use LDAP to store your users and roles, etc. but, you still wanted to use the Login control. Or, you wanted to be able to support LDAP and the default ASP.Net store it in the database and give your user an option? How do you do it?

You create a custom Membership provider. You subclass the ASP.Net membership provider and override as needed, for example, talking to LDAP objects to get user name or verify credentials rather than getting them from the database.

Another example with the member ship provider is something that we do in our app. We have very granular "permissions" (what .Net calls roles). We provide what we call "roles" which aggregate premissions. However, to be able to use the mebership API in ASP.Net we are creating a provider that knows how to get .Net roles for the user which are all the roles assigned to the user, plus all the roles that the user gets because they are assigned to what our application calls "roles". Once this provider is in place all of the ASP.Net API stuff will work exactally the same we have just replaced the implementation.

It is very strategy pattern like, and very usefull!

BOb

Ah thanks! I misunderstood it.

So it's more like the taskperformers architecture in llblgen pro, not like declarative programming like they want to sell you through the page controls. (which IMHO 'can' be useful, but can also not that useful)