This article has been archived. It is offered "as is" and will no longer be updated.
This article contains information about the Microsoft guide Designing Data Tier Components and Passing Data Through Tiers. This guide provides information about how to best expose your data to Microsoft .NET Framework-based applications. It also provides information about how to implement an effective strategy for passing data between the tiers of a distributed application.
Designing Data Tier Components and Passing Data Through Tiers contains the following nine chapters and an appendix:
Introduction This chapter introduces the common tiers of a distributed application. It also discusses data access logic components and business entity components. This chapter also introduces you to the other chapters that appear this guide.
Mapping Relational Data to Business Entities Typically, databases contain data that is organized in many tables. The relationships between the tables are implemented by the primary keys and the foreign keys that appear in these tables. When you define business entities to represent this data in your Framework application, you must decide how to map these tables to business entities. This chapter guides you through the decision-making process.
Implementing Data Access Logic Components A data access logic component is a stateless class that provides methods for gaining access to one or more related tables. Typically, the methods in a data access logic component call stored procedures to perform their operations. This chapter discusses the implementation details that data access logic components handle.
Implementing Business Entities There are many ways to represent business entities in your application. These ways range from a data-centric model to a more object-oriented representation. This chapter describes how to represent business entity data in each of the following formats:
Custom business entity components
Custom business entity components with CRUD behaviors
Transactions Most recent applications must support transactions to maintain the integrity of the data that is contained in a system. There are several approaches to transaction management. However, each approach fits into one of the following basic programming models:
Manual transactions You write code that uses the transaction support features of either ADO.NET or Transact-SQL directly in your component code or in your stored procedures.
Automatic transactions. You can use Microsoft .NET Enterprise Services (COM+) to add declarative attributes to your .NET Framework classes to specify the transactional requirements of your objects at run time. You can use this model to easily configure multiple components to perform tasks in the same transaction.
This chapter provides guidance and recommendations to help you to implement transaction support in data access logic components and in business entity components.
Validations This chapter discusses how to perform data validation in each tier of your application. The following types of validation are appropriate in different tiers:
Client applications can validate business entity data locally, before the data is submitted.
By using an XSD schema, business processes can validate business documents when the documents are received.
Data access logic components and stored procedures can validate data to verify referential integrity and to enforce constraints and nontrivial business rules.
Exception Management This chapter discusses how to handle errors that occur in your application. When errors occur in Framework applications, Microsoft recommends that you throw exceptions instead of returning error values from your methods. The following are two general types of exceptions:
Technical exceptions, including the following:
Connection to database
Resources (such as a database, a network share, or Microsoft Message Queuing) are not available
Business logic exceptions, including the following:
Errors in stored procedures that implement business logic
Authorization and Security This chapter discusses how security applies to your data access logic components and to your business entity components. The Microsoft common language runtime uses permissions objects to implement its mechanism for enforcing restrictions on managed code. There are three types of permissions objects. Each type has a specific purpose as follows:
Code access security You can use these permissions objects to help protect resources and operations from unauthorized use.
Identity You can use these permissions objects to specify the required identity characteristics that an assembly must have to run.
Role-based security You can use these permissions objects to determine whether a user (or the agent that is acting on a user's behalf) has a particular identity or is a member of a specified role. The PrincipalPermission object is the only role-based security permissions object.
Deployment This chapter provides recommendations to help you decide how to deploy data access logic components and business entity components.
Appendix This appendix includes the following topics:
How to Define a Data Access Logic Component Class
How to Use XML to Represent Collections and Hierarchies of Data
How to Apply a Style Sheet Programmatically in a .NET Application
How to Create a Typed DataSet
How to Define a Business Entity Component
How to Represent Collections and Hierarchies of Data in a Business Entity Component
How to Bind Business Entity Components to User Interface Controls
How to Expose Events in a Business Entity Component
How to Serialize Business Entity Components to XML Format
How to Serialize Business Entity Components to SOAP Format
How to Serialize Business Entity Components to Binary Format
For more information, visit the following Microsoft Developer Network (MSDN) Web site: