CSLAGen/Fork is a useful tool, and for getting simple business objects working it's invaluable - however, there are a few things which I think could be improved upon
No "implements/attributes" section for child collection and non-collection properties - I often use attributes to decorate my child properties for my CSLA projects as part of my assistant framework. I can't add attributes to properties and therefore
I'm required to move the code from the .designer file so that my attributes don't get overwritten
Change the way templates are generated to allow more control
I don't know how useful this would be to other people and it might be a good bit of work, but I was thinking that taking each discreet operation that a business object can perform and allowing a user to determine whether it is generated, which file it is
generated to, etc - with a preview window showing the generated code - would be very useful.
This means that if a user wishes, they can move all of the dataportal code into one file, and put business properties and factory methods in another (useful for Silverlight where you need a separate server dll and a shared client/server dll). This also means
that you could potentially split each particular method up into a separate codesmith template file, making the maintenance of the templates easier (yes there would be more files, but it would be infinitely more readable and maintainable when you only need
to edit one file)
I think this would give so much control to the user
Make the Csla object pane a tree view
The object pane does not show the relationship between CSLA objects. I do realise that it's possible to have a child belong to multiple parents - in this case why not just show the object twice? A tree view would solve this issue, giving better visibility
of the object graph. I know there has been some work on the object relations builder and this could also be taken into account in the tree view.
Allow multiple parents for children either by interface or by multi-parent dataportal methods
If this is already done by the object relation builder, then I apologise as I've not really got to grips with it yet.
Nobody likes creating multiple objects which do the same thing - take for example a 'notes' collection which takes two keys 'ID' and 'Area'. The best way I can get CSLAGenFork to represent my objects correctly is to add an interface as an object and then
create my child 'notes' collection which has the interface as it's parent. It's a hack but it works. When this is done, all you need to do is add a new child collection property to your objects and make sure it's of the correct type (childnotecollection),
and also make sure the object implements the interface.
I also have Silverlight versions of the CSLA 4 c# templates - they aren't 100% complete and there are a couple of minor issues - and they are messy when generated with lots of compiler directives but they mostly work. They also generate sync and async
factory methods for Silverlight (using the default property loading for async new). Is it worth posting these or are there more complete ones in the pipeline?