Applies To
- Business entity design in the business layer of an application.
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 how to guide 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 understand the data format’s used Business entities, understand the benefits and liabilities of each, which will help in choosing the correct data format for your 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 used to hold data.
- DataSet – Good for small amounts of data that have limited rules associated with the data. 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 DataSets that can be used independently from a DataSet. A DataTable can be initialized and loaded with data independent of DataSets. Because they do not maintain schema data and changed data they have much less overhead than using a DataSet. DataTables can also be strongly typed similar to DataSets.
- XML – A standards based format that contains structured data. This format would be used when interoperability with other platforms is desired. In addition, XML is often used for file based data used by the business layer. However, it is normally loaded into a document object model or deserialized into objects for use within the business layer.
Each format has benefits and liabilities, which are 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.
Performs much better than other formats due to a smaller footprint, and binary serialization support.
May not map directly to relational structures in a database, which would require 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 to generate XML.
You can define strongly typed DataTables that provide property based access to fields within the table.
They cannot be reconnected to a data source for updates. In other words, they do not provide the same level of disconnected behavior that a DataSet does.
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 have an understanding of the data formats that can be used for business entities the next step is to choose one. There are several different factors that 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 have complex business rules that need to be implemented
- If you are using ADO.NET Entity Framework or ADO.NET LINQ
- If you are working with large amounts 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 the business rules are limited or 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 amount of data that would need to be loaded 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 the business rules are limited or 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 limited or no business rules.
- If you are loading data from XML files that will be consumed by the application.
- If you are designing a service that returns XML data to the consumer.
With the introduction of ADO.NET 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 needed. 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 than other formats in a distributed environment.
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 instance, 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 (fowler). 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 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 (fowler). 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 normally 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 an 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 related to the business domain.
- If you are designing a rich client where the domain model can be initialized and kept 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 in 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 instance, you may have one aspect of the application with complex rules that 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 will need to determine how serialization support is provided by 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 and XML serializer is used and when used with WCF services the DataContractSerializer is used. You can also use .NET serialization by marking objects with a Serializable attribute or implementing the ISerializable interface.
- DataSets – Are already designed to support serialization and can be passed across AppDomain, process and machine boundaries. However, they are usually larger in size when compared to 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, require a connection to a data source, and are not designed to be passed across AppDomain, process or machine boundaries. In other words, the DataReader needs direct access to a data source.
- *XML data* – Serialization is based on how the XML data is represented. However, the .NET Framework provides extensive serialization support for XML data. In most cases attributes are used to control serialization.
FROM : http://www.codeplex.com/AppArch/Wiki/View.aspx?title=How%20To%20-%20Design%20Business%20Entities&referringTitle=How%20Tos
