Monday, February 28, 2005
Passing Data I/O from data Access Tier
there are 4 ways to pass data I/O from data access layer .
1- Scalar Values : In this case, the caller does not need to know the structure of the entity. it is the most efficient input because only the necessary data is passed . The main disadvantage of this approach is that changes in the underlying data structure may require a corresponding change in the method signature . If the method signature needs to be altered to take account of a new field for example , all uses of that method must be tracked down and changed.
2- XML Strings : passing data by using a single data structure .By gathering all of the data for a business entity , exchanges between applications become much more efficient because data is not broken into multiple discrete units. another advantage will be that XML can be digested by almost every application . The disadvantage of this technique is : tagged data introduces reduntant information .
3- Datasets :
a- has optimistic concurrency issues built in on the contrary to ADO objects .
b- can hold collections of data corresponding to individual business entities (implemented as table rows) and are well-adapted to hierarchical data.
c- When a method accepts a DataSet as an input type, changes to the DataSet schema do not require changes to the method signature.
d- incorporate the advantages of XML formats because they can be quickly serialized and deserialized.
Disadvatages : a- big object in memory resulting in high marshaling costs .
4- Custom Entity Components : are implemented as classes or structs(which has better performance . it is a more flexible dynamic way than datasets . they typically represents the underlying business entities (e.g Employee class representing an Employee ). they can also be serialized as XML . they can be created to avoid the high marshaling costs of datasets while gaining the adv of strong typing .
a- representing these entities in Collection will need creating string typed collection or use the ArrayList , which is not the case in Datasets .
b- the custom collections or the builtin collections in .NET doesnt represent the heirarchy , in contract to datasets relations and also provide filtering and sorting .
c- binding to controls . they must implement ICollection to be able to be bounded .
I- DataSets are recommended if the application is primarily workingwith large collections of items and needs standard sorting, filtering,and searching capabilities. This is especially true if the data needs toincorporate complex or hierarchical relationships.
II- If the application mainly works with instance data (for example, a single Customer or Project object), custom business entities will normally be the better choice. There is no need for the overhead of DataSets when only one row of data is sufficient for most purposes.
III- In many cases, the time and effort of creating custom business entities will not be worth