Oct 25, 2011 at 10:24 PM
Edited Oct 25, 2011 at 10:29 PM
I've been quite busy preparing CslaGenFork for Encapsulated Invoke. It was a very big task by itself. I found myself in some Hercules work, with experimenting, refactoring and bug fixing. The last bug fixing involves the criteria class as I found two important
- Encapsulated Invoke needs the criteria class to be moved to the DAL interface assembly
- Silverlight needs the criteria class to inherit from CriteriaBase (or even BusinessBase)
The later is a long standing issue but I found out this was an issue recently, like in yesterday. Until yesterday, I thought that inheriting from CriteriaBase was just an option. In fact, under Silverlight there are serialization specifics that force the
criteria class to inherit from CriteriaBase.
Work have started on the templates. There is still a lot of work to do but I feel I got passed the top of the hill; now it's all down hill. There will be a small detour to the planned course as I have to fix the CriteriaBase issue before continue with the
What's the status?
1) template changes are identified and hand coded samples are working
2) the right templates are executed in the right situations (DAL is needed only for objects that directly interact with the database)
There are 3 sets of templates that need to be changed: business, interface and implementation. There are 10 stereotypes but the total number of files isn't 30 as there is a lot of template re-use.
4) ReadOnlyCollection is working for business and interface; implementation templates for ReadOnlyCollection will be the next thing, right after CriteriaBase.
5) The new Project Validation templates should be the last thing to do. Although validation specifications were written some time ago, the development raises a few more validation needs like "Check no two criteria non nested classes (with more than one
property) have the same name". This validation is needed for Encapsulated Invoke because of this other validation "When using DAL, criteria classes (with more than one property) must not be nested".
What's in the Encapsulated Invoke?
The current release will use IDataReader for fecthes and parameter passing for all other operations. When we need to get two parameters back from the DAL (ID and timestamp), the ID parameter will be passed as "out". So the need for a "results" object was
On subsequent releases, the DTO options will be honoured. No DataTable implementation is planned. This means a new feature must be developed: tri level fecth (grand parent + parent + children).
Note you can follow the progress on the Issue Tracker tab with some clever options like