This project has moved. For the latest updates, please go here.

Encapsulated Invoke using DataReader is closed

Coordinator
Feb 21, 2012 at 5:13 PM
Edited Mar 1, 2012 at 11:08 PM

Encapsulated Invoke follows the model proposed in Rocky's ebook series Using Csla 4. CslaGenFork can generate:

  • SQL Server stored procedures (data layer)
  • Data Acess Layer (DAL interface and DAL implementation for SQL Server)
  • Business layer

The DAL is plugable (DI/IoC pattern) and allows you to write and plug a mock DAL or an Oracle DAL or whatever DAL you prefer.

This was ready by November 2011. Then a new goal was set: handle arbitrary depth data structures. CslaGenFork could handle the deep data scenario, if SelfLoad was used at all levels. The challenge was to make it happen on a single roundtrip to the database - so ParentLoad at all levels. A word of warning: below a ParentLoad object, there can be no SelfLoad objects.

DeepData for Encapsulated Implementation was done by mid-January. Now it's ready also for Encapsulated Invoke (meaning DAL). This is a landmark and new developments are in order: DAL using DTO.

There are two different ways to implement a DAL:

1) No DAL interface objects are used: (ready)

  • Criteria class is on the Business layer
  • the Business layer sends data to the DAL using parameters
  • Fetch operations use a DataReader to get data back from the DAL
  • Insert operations get the new object ID using "out" parameters
  • Insert and Update operations get "timestamp" value as a return value

Note - Fetch operations are dependent on System.Data.

2) Use DAL interface objects: (starting now)

  • Criteria class defined on the DAL interface assembly (can pass Criteria objects to DAL implemention)
  • Data Transfer Objects (DTO) defined on the DAL interface assembly (can pass DTO objects to DAL implemention)
  • single DTO per business class is used to pass values to and from the DAL implemention for Fetch, Insert, Update and Delete operations

Note - No dependencies on System.Data.

The first is the fastest one, since data is read from the DataReader and loaded directly on the Business Object. When you use DTO, the data is read from the DataReader and loaded on the DTO and then copied from the DTO to the Business Object. I don't expect a big time difference, but if you a are a speed freak use the DataReader option.

Why a DTO option? Parameter passing is good enough for up to 7 parameters (according to Steve McConnell in Code Complete). Above 7 parameters, your code becomes very hard to read.