Get your Business and Data Layers talking!

The following sections present the options for passing business entity data to and from your data access logic components, in addition to the advantages and disadvantages of each approach. This information will help you to make an informed choice based on your specific application scenario.


Passing Scalar Values As Inputs and Outputs

The advantages of this option are as follows:

* Abstraction. Callers must know about only the data that defines the business entity, but not a specific type or the specific structure of the business entity.
* Serialization. Scalar values natively support serialization.
* Efficient use of memory. Scalar values only convey the data that is actually needed.
* Performance. When dealing with instance data, scalar values offer better performance than the other options described in this document.


The disadvantages of this option are as follows:

* Tight coupling and maintenance. Schema changes could require method signatures to be modified, which will affect the calling code.
* Collections of entities. To save or update multiple entities to a Data Access Logic Component, you must make separate method calls. This can be a significant performance hit in distributed environments.
* Support of optimistic concurrency. To support optimistic concurrency, time stamp columns must be defined in the database and included as part of the data.



Passing XML Strings As Inputs and Outputs

The advantages of this option are as follows:

* Loose coupling. Callers must know about only the data that defines the business entity and the schema that provides metadata for the business entity.
* Integration. Accepting XML will support callers implemented in various ways—for example, .NET applications, BizTalk Orchestration rules, and third-party business rules engines.
* Collections of business entities. An XML string can contain data for multiple business entities.
* Serialization. Strings natively support serialization.

The disadvantages of this option are as follows:

* Reparsing effort for XML strings. The XML string must be reparsed at the receiving end. Very large XML strings incur a performance overhead.
* Inefficient use of memory. XML strings can be verbose, which can cause inefficient use of memory if you need to pass large amounts of data.
* Supporting optimistic concurrency. To support optimistic concurrency, time stamp columns must be defined in the database and included as part of the XML data.



Passing DataSets As Inputs and Outputs

The advantages of this option are as follows:

* Native functionality. DataSets provide built-in functionality to handle optimistic concurrency (along with data adapters) and support for complex data structures. Furthermore, typed DataSets provide support for data validation.
* Collections of business entities. DataSets are designed to handle sets and complex relationships, so you do not need to write custom code to implement this functionality.
* Maintenance. Schema changes do not affect the method signatures. However, if you are using typed DataSets and the assembly has a strong name, the Data Access Logic Component class must be recompiled against the new version, must use a publisher policy inside the global assembly cache, or must define a element in its configuration file. For information about how the runtime locates assemblies, see How the Runtime Locates Assemblies.
* Serialization. A DataSet supports XML serialization natively and can be serialized across tiers.

The disadvantages of this option are as follows:

* Performance. Instantiating and marshalling DataSets incur a runtime overhead.
* Representation of a single business entity. DataSets are designed to handle sets of data. If your application works mainly with instance data, scalar values or custom entities are a better approach as you will not incur the performance overhead.



Passing Custom Business Entity Components As Inputs and Outputs

The advantages of this option are as follows:

* Maintenance. Schema changes may not affect the Data Access Logic Component method signatures. However, the same issues arise as with typed DataSets if the Business Entity Component is held in a strong-named assembly.
* Collections of business entities. An array or a collection of custom business entity components can be passed to and from the methods.

The disadvantages of this option are as follows:

* Supporting optimistic concurrency. To support optimistic concurrency easily, time stamp columns must be defined in the database and included as part of the instance data.
* Limited integration. When using custom business entity components as inputs to the Data Access Logic Component, the caller must know the type of business entity; this can limit integration for callers that are not using .NET. However, this issue does not necessarily limit integration if the caller uses custom business entity components as output from the Data Access Logic Component. For example, a Web method can return the custom Business Entity Component that was returned from a Data Access Logic Component, and the Business Entity Component will be serialized to XML automatically using XML serialization.