The Microsoft Patterns and Practices Teams need to change their thinking about Enterprise Library.

Enterprise Library needs to be thought of as a provider of services and not a dependency in their various software factories.

This came up again today as I was playing with the Repository Factory and noticed it had a dependency on the old Enterprise Library version 3.0 and not the latest and greatest version 3.1. This will be fixed quickly I am sure, but it is just another example of how the software factories continue to lag behind in the versions of Enterprise Library they are dependent on, making it difficult for developers to use them.

More importantly, however, why should the software factories be dependent on Enterprise Library at all? Why can’t the Data Access Application Block, for example, be a pluggable database helper provider to the Repository Factory?

There are numerous benefits to thinking of Enterprise Library as a provider:

1. We don’t have to deal with the software factories lagging behind the latest version of Enteprise Library. Enough said.
2. Opens up the software factories to people who either don’t like, can’t deploy, or have their own modified versions of Enterprise Library.
3. Allows us to more easily create our own custom providers to plug into the software factories.

Using the above example, the Repository Factory is an ideal place to abstract out the Enterprise Library Data Access Application Block and make it a provider instead of a dependency. The DAAB can be the default provider and making it a provider should not make the Repository Factory any more or less difficult to work with. Seems like a no-brainer.

It is important to draw the distinction between these two mechanisms, however, since they can (and, one might argue, should) be performed by separate systems.

What, then, distinguishes these two mechanisms from one another?

Authentication is the mechanism whereby systems may securely identify their users. Authentication systems provide an answers to the questions:

• Who is the user?
• Is the user really who he/she represents himself to be?

An authentication system may be as simple (and insecure) as a plain-text password challenging system (as found in some older PC-based FTP servers) or as complicated as the Kerberos system described elsewhere in these documents. In all cases, however, authentication systems depend on some unique bit of information known (or available) only to the individual being authenticated and the authentication system — a shared secret. Such information may be a classical password, some physical property of the individual (fingerprint, retinal vascularization pattern, etc.), or some derived data (as in the case of so-called smartcard systems). In order to verify the identity of a user, the authenticating system typically challenges the user to provide his unique information (his password, fingerprint, etc.) — if the authenticating system can verify that the shared secret was presented correctly, the user is considered authenticated.

Authorization, by contrast, is the mechanism by which a system determines what level of access a particular authenticated user should have to secured resources controlled by the system. For example, a database management system might be designed so as to provide certain specified individuals with the ability to retrieve information from a database but not the ability to change data stored in the datbase, while giving other individuals the ability to change data. Authorization systems provide answers to the questions:

• Is user X authorized to access resource R?
• Is user X authorized to perform operation P?
• Is user X authorized to perform operation P on resource R?

Authentication and authorization are somewhat tightly-coupled mechanisms — authorization systems depend on secure authentication systems to ensure that users are who they claim to be and thus prevent unauthorized users from gaining access to secured resources.

1. Always prefer CSS over ASP.NET’s Skins for the following reasons:
   • CSS is a well accepted standard.
   • Designers understand CSS but may not understand ASP.NET’s proprietary mechanisms.
   • Skins lead to Classitis. Each skin creates an html class attribute that has its associated styles. This does not follow the principle of reuse.
   • A well designed external CSS implementation will have a smaller payload and faster download times than its equivalent Skin implementation.
   • Microsoft is heavily investing in tooling for CSS design (Expression Web and inclusion of the Expression Web engine in VS2008), and is really not doing anything more with Skins. So follow their lead. Going forward CSS will have the best tooling support from Microsoft.

2. Use CSS within the Themes construct in ASP.NET in order to get all the good CSS support in VS2008. In particular, instead of linking to CSS files in the <head> section of your HTML document,
   • Create one or more theme folders under the App_Themes folder.
   • Put your CSS files inside these themes folders.
   • Link to these themes by setting the Themes attribute in the page directive.

3. When you drag a control from the toolbox onto your form, ASP.NET, depending on the control, may add inline styling to your control. Delete these inline styles in Code View, otherwise due to the specificity rules, they will override anything you set in the CSS files and you will be scratching your head trying to figure out what happened while trying to find out why the styles you specified are not applied.

4. Furthermore, note that most ASP.NET controls have several formatting properties that can be set via the properties window or directly in the markup. All of these will end up becoming inline styles and should totally be avoided. The only formatting property that I recommend using (in moderation to avoid Classitis) is CssClass.

5. CSS files are written against pure HTML elements not ASP.NET Server Controls. Therefore, understanding the mappings between the two is vital to writing quality CSS files and separating the structure (HTML) from the presentation (CSS). See the bottom of this post for the mappings.

6. Understanding the mappings between ASP.NET web control and HTML types is also vital for making sure that your site is following well established web design standards and guidelines. If you consider using an ASP.NET web control, you need to make sure that the corresponding HTML type was intended for that usage. For example, you can use a LinkButton to submit values to the server. However, the LinkButton converts to an <a href> element (along with some JavaScript that does the postback). The <a href> element is intended for hyperlink. The HTML 4.01 specification clearly states: “A link is a connection from one web resource to another.” To submit data to a server, it is better to use the Button control which converts to input type=”submit”. Why is following these standards important? For example, if we choose the LinkButton over the Button control, if the user has JavaScript turned off, the site will no longer function properly. Also following standards is probably the most important step to making your site accessible.

7. Often times one has to choose between an ASP.NET Server Control and the corresponding HTML element. Here are some rules of thumb. For simple controls like a TextBox or a Label, if you need to map the control to ASP.NET server side functionality, or if you would like to take advantage of the ASP.NET validation controls, use ASP.NET controls. If you don’t, use the lighter html controls. Obviously sophisticated controls such as the Calendar Control can save you hours of development time since they have no equivalents in HTML. On the other end of the spectrum, do not forget that there are a good number of HTML elements that do not have (and should not have) ASP.NET counterparts. An example is <input type=”reset”>. Use these as necessary to do your work.

8. Use the YUI Library CSS Tools. They will save you many hours of work. These tools consist of four style sheets that Yahoo uses for their own production websites. They include a reset style sheet that neutralizes browser specific styles, a base style sheet which creates a consistent style foundation for common HTML elements, a style sheet for setting and managing fonts, and a grid style sheet for managing grids. If you like, Yahoo will even host these sheets for you.

9. Note that you can use ID selectors only with HTML elements. The ID you assign to an ASP.NET Control will most probably change as the HTML is rendered for the control. So for ASP.NET Controls, use the CssClass attribute to define the style. If the control does not have this attribute, wrap it in a <Div> tag. Wrapping in Div tags should be the last resort. Usually you can refactor your CSS by using contextual selectors on Div tags that wrap a group of elements.

10. The designer behaviors in both VS2008 and Expression Web (note that they have the same engine so they work pretty much the same way) focus on styling ASP.NET controls using ID Selectors. This can easily be changed to class selectors. So for a complex ASP.NET web control you add the CssClass attribute with a value. Then, in the CSS file, you add details to it. The CSS designers help you set the CSS properties of the control itself, but to set the properties of individual elements in the control, you need to go in the CSS file and hand code. Remember two powerful CSS selectors, contextual selectors and attribute selectors. (Note that attribute selectors are not supported in IE6 or older browsers). Here is a simplified example:

 <asp:RadioButtonList runat=”server” CssClass=”FunkyRadioButtonList”><asp:ListItem>first</asp:ListItem><asp:ListItem>second</asp:ListItem><asp:ListItem>third</asp:ListItem></asp:RadioButtonList> .FunkyRadioButtonList{/* general styling for the container control goes here*/} .FunkyRadioButtonList input[type=”radio”]{/*styling specific radio buttons in the FunkyRadioButtonList goes here*/}The list below shows the ASP.NET Server control and the HTML element that is generated from it by the ASP.NET runtime.