| Implementation of ASP.NET 2.0 Providers |
|
The Vendidi.Web.Providers library contains custom providers for these ASP.NET 2.0 features:
Membership, Profile, Personalization, Role Manager, SiteMap.
Vendidi Framework classes or new derived classes are used to implement the above set of functionality, made available by ASP.NET for the control of user information and site navigation.
The default implementation of the different providers, as available in ASP.NET, can be labeled as data-centric. There is not much use of object-oriented programming in the way SqlMembershipProvider or SqlProfileProvider persist or retrieve credentials or custom-defined properties to and from the underlying SQL Server. They consist mostly of sequences of ADO.NET operations moving text and numeric values (sometimes also binary chunks, to say the truth) in and out the database. Obviously, there is nothing wrong with this scenario, if not when it comes to extend, for example, the behavior of the user, adding new operations. The problem here is that there’s no behavior to extend, since there’s no such thing as a user. The MembershipUser class, whose instances are created and managed by MembershipProvider, could have been more correctly named Credentials, since this is what it actually is, and the UserName property could have been more suitably called LogonName. With ASP.NET it seems like you first create user’s credentials referring to a not existing user and, only afterwards, you can optionally take advantage of the Profile feature and define instances of the ProfileCommon class, an abstraction certainly much closer to the widely accepted concept of a user. However, a Profile is no more than a set of properties associated to a username with no traces of methods.
Actually, a sort of user entity is somehow implied in all the providers and their related classes, as it appears from the fact that all of them keep referring to it through a username. But, in the default implementation of the various providers, this entity doesn’t make it to reach the “dignity” of an in-memory object and its highest level of reality is represented by a database table, to which all other tables (memberships, profiles, roles, personalization) are linked with foreign keys.
In the Vendidi-based implementation of the ASP.NET providers, the user has been promoted to a full-fledged class, WebUser, derived from the Person class which is part of the Vendidi Framework.
Web site users, be they authenticated or anonymous, are mapped to instances of the WebUser class. This represents a great advantage for the programmer that, thanks to the inherited behavior, can manage a user more easily, both in the context of an ASP.NET application and offline. In fact, its base classes contain operations for handling information commonly considered relevant to an individual (name, gender, different types of addresses, roles, etc.), as well as operations related to database persistency.
The implementation of the custom ProfileProvider based on Vendidi Framework leverages the possibility of defining custom properties for instances of Party derived classes. As with the other providers, central to the VendidiProfileProvider implementation is the WebUser class. One of the arguments provided to the constructor of new WebUser instances is a PartyTemplate, which contains PropertyType objects specifying the types of the custom properties (see Templates) When using VendidiProfileProvider, the configuration file must contain the mapping between a profile property and one of the available property types. The name of the associated PropertyType can be specified using the customProviderData attribute, as shown below for the CompanyName property. When no property type is specified, a default is assumed and it’s named after the corresponding profile property, adding the “cdp” prefix (as with cdpPricePoint).
<profile enabled="true" defaultProvider="Custom">
<providers>
<add name="Custom"
type="Vendidi.Web.Providers.VendidiProfileProvider,
Vendidi.Web.Providers"
applicationName="MyWebApplication"
partyTemplate="StandardWebUser"
/>
</providers>
<properties>
<add name="CompanyName" allowAnonymous="true"
customProviderData="cdpCName"/>
<add name="PreferredBackgroundColor" type="System.Drawing.Color"
allowAnonymous="true" serializeAs="Binary"/>
<group name="AutomobilePreferences">
<add name="CarModels" type="System.Collections.ArrayList"/>
<add name="PricePoint" type="int"/>
</group>
</properties>
</profile>
Consider, moreover, that much of the information usually collected from people visiting your web site (such as first and last name, addresses and so on) can be assigned to properties of the WebUser class, without the need of defining new profile properties.
As for the Vendidi-based RoleProvider, it has been taken advantage of the role management logic built into Vendidi Framework. Therefore, it’s necessary to clarify the terminology used in the two contexts, ASP.NET and Vendidi Frameworks, when dealing with roles.
For the ASP.NET Roles feature a role is nothing more than a string, a label that may be attached to one or more users. In Vendidi Frameworks, role management is based mainly on two classes: RoleType and Role. A RoleType is, actually, what is more similar to the ASP.NET idea of a role, even though it’s semantically richer and functionally more powerful. In fact, it defines the characteristics of a role: a name, a description, a set of responsibilities associated to that role and optional constraints, such as the types who can play it. A Vendidi Role is, instead, the actual association of a Party (or, more in general, of a DomainObject derived class instance) to a RoleType instance. Think of a RoleType as a yet to be filled position within a company. That position will have a name, a description, a list of requirements for those who intend to apply for it, a set of duties and so on. The Role, in Vendidi jargon, may be considered as a position once filled, with a given person occupying it (see Roles).
Although Vendidi Framework allows instances of all DomainObject derived classes to play a role, roles are mostly used with Party and, accordingly, the Vendidi Party class has a good part of its behaviour devoted to role management. Since the WebUser class is derived from Party, all these role-related operations made the implementation of a custom RoleProvider much simple. Moreover, through Vendidi Framework you can define responsibilities, group roles by categories, create a hierarchy of roles and establish relationships between roles.
Since the SiteMap is a hierarchical structure, it seemed natural to use the categories of a Vendidi catalog as elements of the map, in the implementation of a
custom SiteMapProvider. A Vendidi catalog contains categories and products. Each product may have zero or more parent categories. Categories, in turn, may be organized in an n-level graph structure, with multiple root nodes and the possibility for each category of having multiple parents. The structure of the SiteMap is even simpler, since, being a hierarchy and not a graph, each entry may have at most one parent and there’s only one root node (see Catalogs).
Each node of the SiteMapNode has three properties: Url, Title and Description. Therefore, our categories have to contain such information, since, when building the site map, we are going to map each category to a node. This information will be found in some custom defined properties of the category, specified in the sitemap section of the configuration file.
|
|
|
| |  |
|
|
| WebUser delegates management of site access related data to the WebAccessInfo class. |
|
|
|
| VendidiMembershipProvider relies on intances of the WebMembership class for most of its operations. |
|
|
|