I'm trying to put together some code gen examples using CSLA as a proof of concept on a project.
I have used CSLA on another one of my project earlier where I coded everything by hand, and I made use of almost all the base types in CSLA... editable objects, editable lists, editable parents with a read only child list (and editable lsits) etc.
But I want to show that we can codegen a good amount of stuff, and get a good amount of functionality, without generating every type of base class for every table in our DB.
So my plan is to generate a 1) switchable object for each table, and 2) an editable list of those objects.
Now, from a design standpoint, I know this isn't great, but I am willing (and more importantly the decision makers on this project are also willing) to sacrafic a little on the design in order to code gen a lot of usable code.
I believe these 2 classes/table will be a good start in terms of code generation.
Is there anything that I am not remembering about read only lists that would require me to use them instead of editable lists?
What I mean by that is, lets say that there is employee dropdown, where you need to pick an employee. Obviously, this would be a case for a read only list with objects that have probably 2 properties, ID and Name, but I would probably use the generated editable list of employees, and just bind on the fields I need.
I know, from a design standpoint, this is lacking, but is there anything else that would keep this from working that I am not remembering?
cmay:
So my plan is to generate a 1) switchable object for each table, and 2) an editable list of those objects.
Now, from a design standpoint, I know this isn't great, but I am willing (and more importantly the decision makers on this project are also willing) to sacrafic a little on the design in order to code gen a lot of usable code.
Just make sure everyone is willing to live the the performance ramifications of this choice. It isn't just a "purity of design" thing - it is often a performance thing...
If you are using CSLA .NET 3.6 this should be pretty easy. There's no difference between a parent and child object in 3.6, other than the factory and data portal methods.
You can easily code-gen both public root and internal child factory methods, and the child data portal feature makes that a trivial prospect in most cases.
Then you can code-gen both DataPortal_XYZ and Child_XYZ methods, which is also a pretty straightforward thing.
Since the child data portal takes care of marking objects as a child, things are usually pretty simple overall. Look at chapters 4-5 in the 2008 book to see what I mean.
Copyright (c) Marimer LLC