In an n-tier architectural business system design, the function of the data layer is to provide both stateless access to the underlying relational data and a stateful business view of the data that can be consumed by the presentation layer. Stateless data access logic (DAL) components promote effective resource utilization and encourage scalability.

When building effective n-tier systems, the architect is required to make key decisions early in the design process regarding the most efficient way to tie the presentation layer to the underlying data. Business entities (BEs) provide the designer a way to bridge the stateful presentation layer to the stateless DAL that underlies the system. BEs maintain and manage state to provide the programmatic layer that the presentation layer accesses. However, BEs shouldn’t be confused with the business process components, located in the business layer, that define the operations the system must carry out to fulfill its business requirements.

To give you a little more insight into the reasons for implementing BEs, I’ll explain the basics of BE design and the .NET mechanisms for representing them in an application.

Business entity basics
BEs allow you to optimize your data storage architecture and the DAL components that access the data without concern for the users who ultimately need to access the data. If you decide your data must be stored in second or third normal form, or even a combination of those forms that you choose for reading and/or updating efficiency, you can design BEs that represent the data so that the presentation tier can use the data without being tied to its underlying structure. In most cases, the business entities that you create won’t have a one-to-one correspondence with the underlying database tables.

In an order entry system, your database is likely to contain an order header table, order details table, and one or more inventory and pricing tables. But your BEs are likely to be aggregations of these tables. You may choose to implement a BE that represents an order or set of orders which contains both collections and individual elements from each of these underlying tables. In either case, the BE has the current state of a set of one or more orders for a given customer. With the data encapsulated by this BE, it’s easy for a developer to present this order information to a user regardless of whether the presentation layer is implemented in a Windows form or a Web page.

BEs should be implemented so that they can be easily passed to business process components. An order entry system can be vastly simplified if the BE representing a set of orders for a customer information screen is the same BE used to collect information for a new order. This BE can then be submitted to the add-order-business-process component where the data is added to the underlying database using the DAL components. Business process components initiate and manage all transactions. BEs are containers that allow you to pass data between the presentation tier, the business tier and the DAL components; they are not objects that should be involved in transaction management.

Defining business entities
In the COM world, developers had a limited number of tools at their disposal with which to efficiently implement BEs. With .NET, however, Microsoft has provided the tools to allow designers and developers to choose from several potential formats. These include XML documents, untyped datasets, typed datasets, and components.

XML documents
XML documents represent either single objects or collections of objects. An XML document may contain the information for a single order or for a set of orders for a given customer. The key advantage of using XML documents to represent BEs is that any presentation layer front end can process the XML documents that the BEs represent.

Creating XML-based BEs is also simple. You create them directly from an underlying database using the FOR XML clause in a SQL query. You can also create them by first retrieving a dataset and then persisting the XML using the SaveXML method. (This approach isn’t very efficient though, because you pay the processing penalty for creating the dataset.) Finally, you can dynamically generate the XML by processing the values returned from the DAL and using an XMLWriter object to generate an XML document.

Datasets are the ideal choice for representing your BEs. They can contain multiple tables and their relationships and have a simple mechanism for updating the underlying database using the DAL. The dataset can define relationships, primary keys, constraints, and other metadata that makes presentation-layer and business-layer processing more efficient. This is because these capabilities minimize the chance that improper data can be entered into the system. Datasets provide data binding capability “out of the box,” making it simple to create slick user interfaces that consume the BEs.

By using typed datasets, you provide the user interface designer with predefined methods and properties that make it simple to write user interface code. The downside to typed datasets is that if the definition of the BE changes, you have to recompile all of the presentation layer elements that make use of them.

Finally, you can represent BEs by creating custom components that expose public properties representing the state of the underlying data. These properties can be individual data elements or collections that are easily bindable to presentation layer objects. Implementing BEs as components lets you add behaviors to the components using either events or methods. Although components have the potential to allow the richest and most flexible utilization by the presentation layer, they also carry the highest cost in terms of both performance and maintainability.