Want your opinion on CodeSmith templates

Want your opinion on CodeSmith templates

Old forum URL: forums.lhotka.net/forums/t/9919.aspx


wjcomeaux posted on Wednesday, January 05, 2011

Hello everyone. Blake from CodeSmith and I are tossing around some ideas for changes we are making in the CSLA templates. We would like your input regarding the generation of asynchronous methods and Silverlight support.

Right now the templates give you the option of generating code that supports Silverlight or not. We are discussing the idea to generate this code by default and remove the option to include/exclude it. The reasons behind this are here:
PROS:
1) Removing the option makes the template code we maintain simpler.
2) The objects would automatically support Silverlight without having to change a template option and regenerate.
3) Asynchronous methods are useful in any environment, not just Silverlight, so if you want them they are there.
CONS:
1) You lose the option to suppress async methods in the generated objects.
2) Because of #1 there is a more generated code to be maintained/tested (pretty much only the async factory methods)
3) Goes against YAGNI (you aren't going to need it) philisophy -- for developers not using the async methods. (Well, it defies YAGNI in the generated code while preserving YAGNI in the actual code generator <boggle>).

So, what are your thoughts?

Thanks,
Will

richardb replied on Thursday, January 06, 2011

Personally I can live with them being there and thus my objects support Silverlight and other UI's automatically without me having to modify them later or regenerate.  I tend to find that my business layer will end up feeding 2 or 3 UI's over time, plus the async methods are useful elsewhere as you say.

danielmartind replied on Thursday, January 06, 2011

I would be quite happy to generate everything for silverlight. Like you say it is useful to have asynchronous methods in any environment.

What I would find useful is to be able to generate one object at  a time based on stored proceedures as is the case with the CSLA contrib templates.

wjcomeaux replied on Thursday, January 06, 2011

You should forward that request directly over to Blake Niemyjski at CodeSmith, who is in charge of new CodeSmith features. He frequents these forums and he'll probably read this post but to be sure he gets your input you should contact him through the CodeSmith site. Here is the link directly to the CodeSmith forum for Csla templates: http://community.codesmithtools.com/Template_Frameworks/f/68.aspx

Thanks,
Will

rxelizondo replied on Thursday, January 06, 2011

The only real issue that I see is that *I think* (never used CSLA / Silverlight combination) that for Silverlight you need to have a public constructor on your class. If this is really the case then  I am not sure the WPF only guys will be too happy about it.

 

I am not sure if I agree with the CONS 2 and 3 by the way.

   *) For number 2, there is really nothing to test or maintain since the code that the template generates is basically maintained by CodeSmith and it should have already been tested.

   *) For number 3, I see YAGNI as as con only if I am the one that has to produce and maintain code that has a high potential for not being used. If someone else is producing that code for me for free, then I don't have a YAGNI issue. Is kind of like having spell checking ability on the TextBox control, it may be the case that I am never going to use that option but I don't care if its available or not since I an not the one that has to produce or maintain that code.

wjcomeaux replied on Thursday, January 06, 2011

Actually this isn't the case. The generator outputs #if Silverlight blocks around those parts of code. When compiled against Silverlight the constructor is public, otherwise it is private. :)

Will

rxelizondo replied on Friday, January 07, 2011

wjcomeaux

Actually this isn't the case. The generator outputs #if Silverlight blocks around those parts of code. When compiled against Silverlight the constructor is public, otherwise it is private. :)

Will

I see. At first I thought that the templates where no longer going to contain the Silverlight conditional compilation symbol and that things such as the asynchronous method designed for Silverlight where also going to work with WPF / WinForms / etc. So basically one class fits all forcing you to have the public constructor at all times.

In any event, I am not really familiar with Silverlight / CSLA so I probably should not be commenting on this. But even if a public constructor is always visible, if Rocky is going the "have a public constructor all the time" route like Scott mentioned then I would personally be ok with that, no point on fighting it.

tmg4340 replied on Friday, January 07, 2011

Rene Elizondo

The only real issue that I see is that *I think* (never used CSLA / Silverlight combination) that for Silverlight you need to have a public constructor on your class. If this is really the case then  I am not sure the WPF only guys will be too happy about it.

FWIW, I think Rocky has pretty much gone the "have a public constructor all the time" route.  Granted, it sounds like most of his work is in Silverlight these days, but I don't consider the "cost" of a public constructor to be all that high.  Admittedly, you do lose that level of protection, but I don't consider it difficult to teach developers to use/build factory methods instead of relying on a constructor.  Additionally, you are automatically ready if/when you do develop a SL UI.

- Scott

bniemyjski replied on Friday, January 07, 2011

 

Hello,

I've been wanting to read over his new ebooks as well as do some more research. I think that maybe we should just only wrap the constructors in if blocks but leave the Async methods to be a generation time option. This way if you are using WPF, WP7 or Silverlight you can still use the ASYNC methods without all of the extra if directives. Thoughts?

Also, I've done a lot of work for generating off of views and stored procedures, and edmx file possible. I was curious as to how many of you prefer to generate from an edmx file compared to views, stored procedures or just an XML file as it will determine where I first spend my efforts upgrading the templates.

Thanks

-Blake Niemyjski

 

lukky replied on Wednesday, January 12, 2011

Blake,

I like the idea of generating from an edmx file, but are you talking about just the BO generation, or are you planning on integrating EF as the data access technology ?

Thanks

bniemyjski replied on Wednesday, January 12, 2011

Hello,

We would be offering support for both.

Thanks

-Blake Niemyjski

Copyright (c) Marimer LLC