Interdev DTCs are legendary for the number of developers who were suckered into using them for a simple application, only to find that they had to rewrite the functionality from scratch when they wanted to extend them or modify their output because the DTC was neither modifiable nor extensible. Consequently, when I first saw the .NET DataSet object, I was cautiously optimistic. Unfortunately, many developers chose not to be cautious at all.What’s wrong with the DataSet?
I’m not saying that there’s anything inherently wrong with the DataSet object. But it’s like any other tool—you need to understand how to use it appropriately. Although it’s a useful tool for Windows Forms applications, it’s much less useful for Web application development.

Let’s look at a simple example. Suppose you use a DataSet to return a set of 1,000 products to display in a DataGrid on a form. Since you might want to sort or filter the data later, you choose to save the DataSet in a session variable. Not knowing any better, you also leave the default page ViewState turned on. When a user navigates to this page, there are three copies of the data somewhere in memory. It’s on the server saved in a session-level variable. It’s in the ViewState stored as the contents of the DataGrid. And it’s in the rendered HTML stream in the form of HTML table directives that render the table. Now multiply the server memory by the number of users to assess impact on server memory, and multiply the two copies of the data by the number of users to assess the impact on bandwidth utilisation. You can quickly overload a server and its available network bandwidth on a high-traffic site.

The answer: Use the DataReader
Though not as sexy, the DataReader is much more functional for a Web application. Because the DataSet object’s cursor is designed to iterate in a forward-only, read-only fashion over the results of a query, it’s very fast. Moreover, the DataReader only holds the current record in memory at any one time—never the entire results set. The DataSet object can be bound to ASP.NET Server Controls (like the DataGrid). More importantly, server resources and connection resources are released as soon as you’re finished traversing them. Build your data-bound pages using DataReaders to retrieve data from an underlying database whenever it’s important for the data to be as fresh as possible.

When should I use the DataSet?
The only time I recommend using the DataSet in a Web application is when the underlying data changes on an occasional basis. For example, if you have a series of drop-down boxes or checklist items that come from a database but rarely change, it may make sense to load them in a DataSet in the Application_OnStart event and put them into the cache so that any page that needs to get the values will have them immediately available. This not only makes data retrieval faster for each page but also minimises the number of hits to the underlying database. You can get an additional speed boost by caching the Web pages, which rely on the cached DataSet for their values.

By setting a dependency between the cached Web pages and the cached DataSet, the Web pages will be regenerated whenever the DataSet changes. To make sure the DataSet is always current, you should create Update, Insert, and Delete triggers on the tables in the DataSet that modify a control file on the site. Then set a dependency between the cached DataSet and the control file. Whenever the control file changes, the DataSet in the cache will be invalidated. Add code to the Session_OnStart event to check for the cached DataSet, regenerate it if necessary, and place it back in the cache. Then whenever the underlying tables change, the cached DataSet will be regenerated.

Using the right tool for the right job is the best way to create optimised Web applications. Now you have some general guidelines for the right time to use the DataReader and the DataSet in your ASP.NET applications.

.NET assembly represents both a deployment and a loadable unit of code and metadata. To develop systems that can be deployed efficiently, system architects must consider the proper location for each component in a .NET application. Unfortunately, there are no hard and fast rules.

Many times I would consider an assembly boundary to be the boundary between the tiers (presentation, business, and data) of an application as well, but there are just as many cases where I would break the processing tasks handled by a specific tier into two assemblies in order to accommodate a technical requirement.

One component per assembly or project
Unless the component is incredibly complex—which isn’t a good thing anyway—this level of granularity makes development projects difficult to manage. Developers working on even a moderately sized project would find it difficult to code between all of the component files. Moreover, it becomes a deployment and support nightmare since you must deal with versioning issues caused as new versions are introduced into the production environment. Visual Basic developers have grown up working this way since versions of VB that came out before .NET only supported a single class per file. But now that developers using any .NET language can manage multiple classes per file, it makes more sense to group related classes together. The one component per assembly approach also makes the application more resource-intensive at runtime. More components mean longer load times, and more memory and processing overhead to manage them.

One assembly for each tier in an application
For many small to medium-size projects, it makes sense to put all of the components related to an application tier into the same assembly. The logical separation between presentation layer, the business logic layer, and the data access layer is basically an architectural way to minimise the amount of additional work necessary to add features to any layer that can be consumed by another layer. It would seem to make sense to physically separate the components into assemblies that represent each tier of the application. While this sounds good from a theoretical perspective, there are operational reasons against it.

You should consider locating the presentation layer and business logic or business logic and data access layers in the same assembly where it’s required, to ease deployment and systems management concerns. For example, this distribution of functionality will almost always be a requirement in tightly coupled, highly transactional environments where the decrease in an applications’ execution speed created by separating the business logic from the database logic would keep the application from meeting the business need for efficient transaction processing. By deploying separate assemblies for the business and database tiers, you incur the additional overhead of calling cross process and (in a physical three-tier deployment) cross machine, both of which take a considerable toll on the overall speed of the system. Placing two of the three tiers in the same assembly and on the same machine eliminates both of these bottlenecks.

Assemblies by function rather than by tier
In more complex applications, it sometimes makes sense not to create assemblies based on tiers, but instead to create the separation based on function. For example, you should consider grouping business logic and its associated data access logic for a subsystem of a larger solution in a single shared enterprise services package. This way, you run the presentation logic or a business facade on one machine and then consume this subsystem from another machine. Breaking up functions this way also allows the subsystems to be reused in multiple applications more easily than sharing just a data access layer.

When designing your application, take the time to consider how you’ll design assemblies to match your deployment objectives. I’ve seen many cases where the architect makes wise design decisions on how to compartmentalize the functionality of the components in a system, only to have the application fail because of a lack of proper deployment planning.

Since attributes are new to both C++ and VB developers, there’s no context for easy comparisons to familiar language elements. But the addition of attributes to the Common Language Runtime (CLR) gives developers new abilities to associate information with their classes via an annotation mechanism, which the CLR can then use to operate on the objects at runtime.

Attributes can be used to document classes at design time, specify runtime information (such as the name of an XML field to be used when serialising information from the class), and even dictate runtime behavior (such as whether the class should automatically participate in a transaction). More importantly, you can develop your own attributes that specify architectural standards and enforce their use. In this article, we’ll look at how the CLR uses standard attributes and how and why you should create your own attributes.

What is an attribute?
Many .NET developers get their first exposure to attributes when using templates provided in the Visual Studio environment. For example, when a VB developer creates a new XML Web Service, they get back sample code that defines the Web Service to the CLR using attributes like this:

 _
Public Class Service1
Inherits System.Web.Services.WebService

The class Service1 is said to have been “decorated� with the WebService attribute, and the NameSpace variable has been assigned the value of http://tempuri.org/. The WebService and WebMethod attributes signal the compiler that these attributes should be accessible using the SOAP protocol. As you can see from this example, the purpose of .NET attributes is to signal a compiler or the runtime to generate MSIL or to operate on the MSIL generated, based on metadata representing the attribute. There are many other examples of using attributes to instruct the compiler how to generate the appropriate MSIL, including:

• Using MarshalAsAttribute to tell the compiler how to marshal method parameters when interoperating with native code.
• Using COMClassAttribute to mark components as COM so the Visual Basic compiler will generate code allowing a .NET component to be called from COM.
• Using attributes to describe the resulting assembly with title, version, or description information. The version information is especially important when using signed assemblies and the Global Assembly Cache because you can force the runtime to load only particular versions of assemblies and avoid the COM DLL Hell problem.
• Mapping class members to specific XML node types when defining XML serialisation.

When compiled, attributes are saved with the metadata of the finished assembly. At runtime, the CLR or your own programs can still use any attributes used by the compiler to control code generation by using reflection to query the assembly for the values specified by an attribute. The feature that makes attributes most powerful, however, is their ability to add additional capabilities to any language hosted within the .NET runtime without making changes to the language compilers.

Adding language capabilities
Attributes are not language specific. Just as we can decorate the HelloWorld method in VB with the WebMethod attribute, there’s a similar implementation for C#:

[WebMethod]
public string HelloWorld()
{
return "Hello World";
}

Since attributes are language independent, you can define new functionality by creating attributes that inherit from the System.Attribute class. You can then apply that functionality to programs written in any language by simply decorating the appropriate classes, methods, or properties at design time.

For example, one company that I’m working with has defined its own extensions to the CLR that implement metering via performance counters and dynamically created usage statistics. The company has implemented the functionality by creating a set of attributes that can be applied at the module, class, method, event, or property level at design time. Once these attributes are applied, the compiler can include their code to implement this functionality at compile time and the CLR can use reflection to collect the information defined by the attributes at runtime. Using this mechanism allows the company to implement standard metering and usage statistics functionality across all its .NET systems.

Attributes are a good thing
The implementation I’ve discussed here is just one example of how companies are using .NET attributes to standardise operations across their development efforts. .NET Architects who take the time to examine and apply this new technology will undoubtedly find other ways to use it in the applications they design.

When it comes to building and implementing an IT policy, no quick-fix or one-size-fits-all solution will adequately serve your needs. Every business is different, and the approach taken to meet objectives and/or ensure compliance will vary from one environment to another, even in the same industries. But you can take advantage of certain best practices to increase your odds of crafting and implementing a policy that employees will support and that will help protect your organisation.

Executive support

For starters, no policy will succeed without the basic buy-in from senior leadership. Senior executives, directors, and managers should be asked to provide input and some form of approval to the policy. Obtain a clear statement of support before you start creating the policy and continue to keep senior management educated and involved as it is written. When the policy is ready for implementation, request that management formally present it to your organisation, stressing its importance.

Consensus building

As you begin formulating a policy, you should involve all interested parties in the discussion of its establishment by creating a committee. Your committee should consist of the owner of the policy, subject matter experts, frequent users of the policy, and representatives from groups affected by the policy. You may also want to consult specific groups within your particular organisation, such as Human Resources, Financial, and Legal. These groups can make recommendations based on the impact of the policy on the organisation as well as on its viability and legitimacy. This will ensure the policy you develop is fully understood by everyone concerned and that it has their backing once it’s implemented. That broad base of support is one of the best assurances for policy success.

Policy contents

Although policies vary from organisation to organisation, a typical policy should include a statement of purpose, description of the users affected, history of revisions (if applicable), definitions of any special terms, and specific policy instructions from management.

Make sure everyone has a clear understanding of the purpose of the policy. Are you creating this policy because you have to be in compliance with some ruling? Are you trying to cut down on costs or create additional savings? Are you ensuring liability will not be placed on the company?

Creating a uniform policy format to ensure that information will be presented to the reader in a consistent manner is paramount for policy success. A uniform format will make the policy easier to read, understand, implement, and enforce. Keep the scope of your policies manageable as well. Consider making separate, smaller polices that address specific needs.

The language of your policies must convey both certainty and unquestionable management support. Remember, you’re setting policy, not describing standards. A standard would, for example, define the number of secret key bits that are required in an encryption algorithm. A policy, on the other hand, would dictate the need to use an approved encryption process when sensitive information is sent over the public Internet system.

Standards will need to be changed considerably more often than policies because the manual procedures, organisational structures, business processes, and information system technologies change much more rapidly than policies. You can reference standards within a policy and modify that standard as the technology or compliance requirements change.

After you roll out a policy, you may see many examples of inappropriate use or violations, but it’s difficult to anticipate them. So it’s important to have catch-all clauses within your policies, such as:

• “Viewing or downloading offensive, obscene, or inappropriate material from any source is forbidden.”
• “The storing and transfer of illegal images, data, material, and/or text using this equipment is forbidden.”

Research and preparation

In drafting your policy, you will want to research related issues both inside and outside the company. Some common areas to research include:

• Company policy library (if you have one)
• Forms and documents required to develop or complete the policy: request forms, legal documentation, etc.
• State and or federal laws that are relevant to your policy
• Similar policies at other businesses

One of the biggest mistakes many companies often make when they begin designing policies is to create guidelines and restrictions without any understanding of how the company’s business actually works. Although there’s always going to be a factor of inconvenience with any security policy, the goal is to create a more secure environment without making things overly difficult or hard to understand for the people having to use the resources the policy is trying to protect.

Policies made outside the company’s business model will begin to become circumvented over a period of time and the overall environmental state can become worse than before the security measures were implemented. So make sure part of your research involves developing a solid understanding of business processes so that your policy can work with them, rather than against them.

Policy reviews

Even after you’ve finished drafting or updating a policy, the job is not complete. The policy should be reviewed by legal counsel to ensure that it complies with state and federal laws before it’s finalised and distributed to employees. Further, you should review the policies on a regular basis to make sure they continue to comply with applicable law and the needs of your organisation. New laws, regulations, and court cases can affect both the language of your policies and how you implement them.

Most experts suggest a thorough review of your policies at least once a year and the use of a dedicated notification system/service to keep employees informed of changes. And when revised policies are introduced, you should formally distribute and thoroughly explain them to all employees.

Policy pointers

• Consider holding (depending on the size of your company) a series of meetings that involves all interested parties.
• Do not fill policies with “techie” terms. Polices must be written in layman’s terms or the concepts may be lost on the end users.
• Set out what behavior is reasonable and unreasonable and determine procedures for dealing with specific abuses.
• Try to keep polices to the point. Long written polices are difficult to read and comprehend, and users may be confused or simply give up on trying to understand them.
• Agree upon a framework for policy review. Usage and technology may change, so you need to be flexible and adapt the policy when it is required.
• Decide, define and mandate “what” is to be protected.

Done right…

Well-crafted policies show that an organisation and its management are committed to security and expect employees to take it seriously. Such policies provide an overall security framework for the organisation, ensuring that security efforts are consistent and integrated rather than ad hoc or fragmented. A good, regularly reviewed policy can be both an effective employee relations tool and a helpful defense against lawsuits. In contrast, policies that are poorly drafted or misapplied can decrease efficiencies and create roadblocks for normal business activities. Invest the necessary amount of time and effort to make sure your policies are solidly built and properly implemented.