Hi, there.
I want to generate csla business classes based on a) my database b) on my entity frameworkmodel.
a) base: database/ technology: Raw Ado DotNet = Codesmith code generator
Codesmith's code generator looks ok. What you do think about this generator? Is there a better one?
b) base: Entity Framework model/ technologie EF= Codegenerator->CslaExtension 1.0.1 (http://t4csla.codeplex.com/ )
This code generator looks ok as well. What you do think about this generator? Is there a better one? This project doesn't look very busy as their latest version is two years old. Is it save to use it or is it a death end?
Please share your valuable opinions with me. Thank you for your help.
ciu
Manfred
Hi Manfred,
You can have a look at CslaGenFork - an Open Source project that is under active development. Although in RC status, in fact it's a stable release.
Thank you very much. I will have a look.
Hi, Tiago
I looked through CslaGenFork. It looks very good. Is using stored procedures a must? I want to use plain old sql statements. Do I have this option?
Thank you for your effords.
ciu
Manfred
Hi Manfred,
Presently CslaGenFork only generates stored procedures and genertates the code that calls those stored procedures. Generating inline SQL queries is on the road map.
If you can't use stored procedures, there is a workaround but you loose something. First of all the workaround.
Let's suppose your data model (what's in the database) doesn't change.
1) Generate for CSLA40 using a DAL - the code that calls the database is isolated on the DAL
2) Edit the DAL code as fit
You might need to rerun the code generation in order to add or change business or authorization rules. These changes only affect the business layer so it's all right to keep the DAL unchanged.
3) On subsequent runs of the generator, disable DAL generation so you don't overwrite your changed DAL.
What you loose is the ability to fully re-generate the whole project - DAL included, in case your data model changes. Re-generation is perhaps the most important feature of code generation. So this workaround is something you should not do, unless you are 120% (!!!) sure your data model won't change. This may happen when you are porting an existing application to CSLA .NET. If you are coding some new features for some existing application this may or may not happen.
If you are writing a new application I don''t believe this will happen - customer requisites will change too much and these changes will also affect the data model. If using inline SQL queries is a requisite, use stored procedures during the development phase until the customer is happy and stops asking for new features. At that point go for inline SQL.
Hi, Tiago
Thank you for your very kind answer. Your editor looks very powerfull! Saidly I dont want to use stored procedures. How far SQL Statements in DAL are away?
ciu
Manfred
Hi Manfred,
This feature isn't planned for the the near release. The plans are likely to change as CSLA 4.5 needs some special attention. I won't have time to re-evaluate the plans for the next weeks. So I can't make any promises.
Regards
Hi, Tiago
No worries. I am impressed by your editor. Do as you please. Thank you for your answer and your work.
ciu
Manfred
Hi
I'm using ClsaGenFork a ReadOnlyCollection, but the it doesn't generate all the properties for the columns in the table. Is there a limit?
Thanks
Sorry found what the problem was.
Hi ozitraveller,
I'm glad you found the problem. In the future, please use CslaGenFork Discussions area.
Regards
Copyright (c) Marimer LLC