How To: Design Business Entities

J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat.

Applies To

  • Business entity design
  • Business layer

Summary

Business entities are used to contain and manage business data used by an application. They should not contain any data access or business processing logic. Business entities should provide validation of the data contained within the entity. In addition, business entities provide properties and operations used to access and initialize data contained within the entity.

Contents

  • Objectives
  • Overview
  • Summary of Steps
  • Step 1 – Identify Common Data Formats.
  • Step 2 – Choose the Data Format.
  • Step 3 – Choose Your Design for Custom Objects (Optional).
  • Step 4 – Determine Serialization Support (Optional).
  • Additional Resources

Objectives

  • Understand data formats and how the data will be used in the application
  • Understand how rules affect the design of business entities
  • Choose an appropriate design if using custom objects for business entities.
  • Determine how serialization is supported by different data formats.

Overview

This article starts with a look at different data formats and how data will be used in your application. Next, you will learn how the data format you choose determines how business rules can be implemented in your design. Finally, you will learn about design options for custom objects, and how to support serialization with different data formats.

Summary of Steps

  • Step 1 – Identify Common Data Formats.
  • Step 2 – Choose the Data Format.
  • Step 3 – Choose Your Design for Custom Objects (Optional).
  • Step 4 – Determine Serialization Support (Optional).

Step 1 – Identify Common Data Formats for Business Entities

In this step, you will learn about the data formats used in business entities, and see the benefits and liabilities of each, to help you choose the correct data format for your own scenario.

The common formats used to represent business data are DataSets, XML, and Custom objects.
  • Custom Objects – Best suited for applications that have moderate to complex business rules associated with the data, but they can be used with any application type. There are two main design patterns associated with custom objects: Domain Model and Table Module. However, custom objects can also be used to represent XML structures, list items in a SharePoint list, or any other structure that holds data.
  • DataSet – Good for small volumes of data that has few associated rules. There are two types of DataSets: standard and strongly typed. A standard DataSet uses string-based names to access the data, while a strongly typed DataSet provides a property-based interface to the data.
  • DataTable – This is a component of the DataSet that can be initialized and loaded with data independently. Because they do not maintain schema data and change information, they have a lower processing and memory overhead than a DataSet. DataTables can also be strongly typed, in a similar way to DataSets.
  • XML – A standards-based format that contains structured data. This format is often used when interoperability with other platforms is desired. In addition, XML is often suitable for file-based data used by business layer. However, it is usually loaded into a document object model or de-serialized into objects for use within the business layer.

Each data format has benefits and liabilities, as listed below.

Data Format Benefits Liabilities
Custom Objects Can support both connected and disconnected scenarios. Entity design can be complex, especially when using a domain model design, which requires domain-modeling experience.
Perform much better than other formats due to a smaller footprint, and binary serialization support. May not map directly to relational structures in a database, therefore requiring a mapping layer.
Can be used to represent complex relationships, and support complex rules. Serialization support is not automatic; you must declare objects as serializable or implement serialization support.
Can be passed across AppDomain, process, and physical boundaries.
Can be bound to controls in the user interface.
Wide range of options for entity design.
ADO.NET Entity Framework and ADO.NET LINQ provide extensive support for mapping custom objects to data sources.
DataSet Good for disconnected scenarios where you open a connection to the data source, load the DataSet, and close the connection immediately. DataSets contain both the data and the data schema, which means they have a larger footprint than any other data format.
Can be passed across AppDomain, process, and physical boundaries. Although based on XML, the complexity of the DataSet schema is not easy to read, parse, and understand, which limits their interoperability.
Changes to data in a DataSet can be tracked while maintaining both the original and changed data. Access errors with standard DataSets are not discovered until runtime because string based names are used to access the data.
Can be reconnected to a data source in order to persist changes made to the DataSet.
Supports filtered views of the data.
Can be bound to controls in the user interface.
DataTable Much less overhead than using a DataSet. Access to fields in a standard DataTable uses string-based accessors, which can lead to defects that are not discovered until runtime.
Supported by ADO.NET DataAdapters for Fill operations. Must be included in a DataSet when generating XML.
You can define strongly typed DataTables that provide property based access to fields within the table. Cannot be reconnected to a data source for updates. In other words, they do not provide the same level of disconnected behavior as a DataSet.
Supports filtered views of the data.
Can be bound to controls in the user interface.
XML Supports interoperability with different platforms. Requires extra code to consume the XML data for use within the business layer.
In its raw format, XML data can be manipulated with simple text editors. Has a larger footprint than custom objects because XML data contains both the data and structure.
Can be passed across AppDomain, process, and physical boundaries.
The .NET Framework provides extensive support for working with and managing XML Data.

Step 2 – Choose Your Data Format

Now that you understand the data formats that can be used for business entities, the next step is to choose one. Several different factors should be considered. For example, complex rules are better handled with custom objects, while a small document based application would benefit from the use of XML documents.

Consider using custom objects:
  • If you must implement complex business rules.
  • If you are using the ADO.NET Entity Framework or ADO.NET LINQ.
  • If you are working with large volumes of data.
  • If you want to maximize performance when passing data across AppDomain, process, and physical boundaries. Custom objects can be serialized using a binary format, which is much faster than XML formats.

Consider using DataSets:
  • If there are few business rules, or they are managed by an external business rules engine.
  • If you are designing a small Web application or service, and you want to take advantage of the disconnected behavior provided by DataSets.
  • If your application does not use a large volume of data that you need to load into the DataSet.
  • If you already have DataSets defined, but are refactoring the application to take advantage of new features in ADO.NET LINQ. In this case, you can use the LINQ to DataSet provider.

Consider using DataTables:
  • If there are few business rules, or they are managed by an external business rules engine.
  • If you are designing an application that uses ADO.NET providers, and want to take advantage of ADO.NET adapters to fill the DataTable.
  • If you do not need the disconnected behavior provided by a DataSet.

Consider using XML:
  • If you are designing a content-based application with few or no business rules.
  • If you are loading data that will be consumed by the application from XML files.
  • If you are designing a service that returns XML data to the consumer.

With the introduction of ADO.NET Entity Framework (EF) and ADO.NET LINQ, custom objects are the recommended choice for new applications that take advantage of these new features. However, you can also use LINQ to SQL for an existing application that already has DataSets defined. XML data can also be de-serialized into custom objects, which can then be serialized back into XML as required. With most new designs, you should always consider custom objects as a first choice, which are now supported by ADO.NET and generally perform much better in a distributed environment than other formats.

Step 3 – Choose Your Design for Custom Objects (Optional)

If you have determined that custom objects provide the best data format for business entities, the next step is to design those objects. The design approach used for custom objects is based on the type of object that you plan to use. For example, domain model entities require in-depth analysis of a business domain, while table module entities require an understanding of the database schema.

The following is a list of common design approaches when using custom objects:
  • Custom XML Objects represent de-serialized XML data that can be manipulated within your application code. The objects are instantiated from classes defined with attributes used to map properties within the class to elements and attributes within the XML structure. The Microsoft .NET Framework provides components that can be used to de-serialize XML data into objects and serialize objects into XML.
  • Domain Model is based on an object-oriented design pattern named Domain Model. The goal with a domain model design is to define custom objects that are based on an analysis of the business domain. When using a domain model design, the business or domain entities contain both behavior and structure. In other words, business rules are encapsulated within the domain model. The domain model design requires in-depth analysis of the business domain and typically does not map to the relational models used by most databases
  • Domain Value Objects are lightweight objects that represent domain entities, but do not contain business rules. These objects are sometimes referred to Data Transfer Objects (DTO), which is a design pattern used to package multiple data structures into a single structure for transfer across AppDomain, process, and physical boundaries. With a domain value object, the main goal is to define business entities that represent entities in the business domain while maintaining the relationship between those entities.
  • Table Module is based on an object-oriented design pattern named Table Module. The objective of a table module design is to define entities that represent tables or views within a database. Operations used to access the database and populate the table module entities are usually encapsulated within the entity. However, you can also use data access components to perform database operations and populate table module entities.

Consider using Custom XML Objects:
  • If the data you are consuming is already in XML format. For example, XML files or database operations that return XML as the result set.
  • If you need to generate XML data from non-XML data sources.
  • If you are working with read-only document-based data.

Consider using Domain Model:
  • If you have complex business rules that relate to the business domain.
  • If you are designing a Rich Client and the domain model can be initialized and held in memory.
  • If you are not working with a stateless business layer that requires initialization of the domain model with every request.

Consider using Domain Value Objects:
  • If you have business rules that can be handled by external processing components.
  • If you are working with a stateless business layer where you are required to initialize business entities with each request.
  • If you want to use business entities that represent the business domain without encapsulating rules within the entities.

Consider using Table Module:
  • If tables or views within the database represent business entities used by your application.
  • If you are working with either a stateless or stateful business layer.

When using custom objects, it is also not a requirement that all business entities follow the same design. For example, one aspect of the application with complex rules may require a domain model design. However, the remainder of the application may use XML objects, a table module design, or domain value objects that do not contain business rules.

Step 4 – Determine Serialization Support (Optional)

If your application design is distributed across AppDomain, process, and physical boundaries, you must determine how serialization support is provided for different data formats.
  • Custom objects – As with XML data, serialization is based on how the custom object is used within your design. When used with Web services, an XML serializer is used. When used with WCF services, the DataContractSerializer is used. You can also use .NET serialization by marking objects with a Serializable attribute or by implementing the ISerializable interface.
  • DataSets – These automatically support serialization and can be passed across AppDomain, process and machine boundaries. However, they are usually larger that the equivalent custom objects.
  • DataReaders – While DataReaders are not used to represent business entities, they are often used to retrieve data and initialize custom objects. The DataReader itself is not serializable, requires a connection to a data source, and is not designed to be passed across AppDomain, process or machine boundaries. In other words, the DataReader requires direct access to a data source.
  • XML data** – Serialization is based on how the XML data is represented. The .NET Framework provides extensive serialization support for XML data. In most cases, attributes are used to control serialization.

Additional Resources

Last edited Dec 17, 2008 at 7:35 PM by prashantbansode, version 3

Comments

johnrusk Oct 2, 2008 at 8:35 AM 
The introduction says: "They should not contain any data access or business processing logic" - but the second half of that sentence is at odds with the subsequent (and correct) description of the Domain Model pattern.

How is "Domain Value Objects" different from the "Anemic Domain Model" : http://www.martinfowler.com/bliki/AnemicDomainModel.html ?

Would Domain Value Objects necessarily be used as the primary entity structure for the application? I would have assumed not, and rather expected that their use would be limited to cases where remote calls were involved. Reasons are as per: http://martinfowler.com/bliki/LocalDTO.html

Is it accurate, in general, to say that the Domain Model "typically does not map to relational models used by most databases"? I like the earlier suggestion that ADO.NET LINQ is a good default choice. In cases where you control both the data model and the object model, for instance when building a new system and DB from scratch,I believe you can make them similar enough that you can implement the Domain Model pattern well (even with the mapping limiations imposed by LINQ to SQL). So, is it correct to say the the Domain Model pattern typically doesn't map well to relational DBs? Or would it be more accurate to say that it "may not map easily to _legacy_ relational database structures"?