Lessons from the last year of CSLA codegeneration.
Jul
28
WRITTEN BY:
28/07/2010 12:56 AM
Jenasys Design decided to use the CSLA with our software solutions. CodeSmith’s Blake Niemyjski created a new set of templates for the CSLA. Our business contributed time reviewing, suggesting, discussing, debugging and contributing to CodeSmiths CSLA templates. We did this for our customers benefit at no cost. It allowed our customers to move their software from CSLA 2.0 to 3.0 to 3.8.x in a very short period of time.
Favorite Features
- The folders and files generated are very clean.
- Business Object naming standards and renaming features ensure we can fix old database naming standard, typos and spelling mistakes.
- Generates both VB and C# matching code, making it easy to swap languages as required by customers.
- Implements CSLA 3.8.x and 4.0 to the methodology defined in Rocky's books and online (including Silverlight features).
- Implements standardised CSLA code used by other developers, rather than the hacked, poorly implemented CSLA code we previously created.
- Encourages database and application re-factoring.
- We are very happy with the code generated.
Improvements over CSLAContrib Templates
There are a significant amount of qualitative improvements over the CSLAContrib templates, which are subject to opinion, but here are my thoughts on the improvements.
- Code structure easy to follow
- Easy of debugging (no delegate methods).
- Easy of code injection (partial methods).
- Database maintainability (not generating too many objects).
- Easy of field renaming (KeywordRenameAlias.csmap).
- Improved CSLA.Security.Authentication configuration (code generated for you).
- Database null field support helping remove CSLA.SmartDate code.
- Good naming conventions.
- Code template design, makes it easier to identify and modify code generated if required!
- CSP project allows you to integrate your entire CSLA object configuration in one location. (Previously you had to save in XML files and load manually).
- Good community support, feedback, code styles and bugs with the templates, ensuring everyone benefits, developers and customers.
Lessons Learnt using CodeSmith CSLA templates
You can’t upgrade all your code to CodeSmith created CSLA when working with medium to large database applications. We recommend that you convert the CSLA code on business object and screen at a time.
- Setup a CodeSmith Project -> Output entry to match each GUI component. It makes it easier to isolate the CSLA code configuration (or modify it at a customer’s request).
- Where possible use the Entity template as it helps create all the relationship objects. In highly normalised databases you will need to use the 1.DataSource -> IgnoreExpressions to restrict the code generator from going too far. TIP: Create SQL Server diagram to match each CSLA Business Object. This helps explain the Database versus Business Object(s) relationship. It also helps the next developer(s) who inherit your database application.
- If you want a custom named object or a CSLA Business Object that doesn't map well to a table, then I use the specific Stereotype template.
- If you really need something customized, use a temporary database, and then create the table(s), which can be used to generate the CSLA Business Objects you need. TIP: Use the Partial Methods to replace the DataPortal code.
- When creating a new GUI with the same style as an existing CodeSmith Project Output, use the copy and paste feature and then swap the CSLA stereotype tables. TIP: In Visual Studio, open the *.csp as XML and copy and paste XML around or use Find and Replace.
- Do not assume the CSLA code output works! Existing Unit tests helped us identify code modifications and bugs. It’s very helpful when jumping CSLA editions. TIP: Submit bugs to CodeSmith with a SQL script and a copy of your CodeSmith Project that generated the bug. This speeds up resolution times and benefits all the community.
COPYRIGHT ©2010 Jenasys Design Pty Ltd