Hi everyone,

I am currently evaluating some options in Data Access Layer solutions. Thanks to Frans Bouma's post about this issue I now have some points to start with.

Having played a little bit with LLBLGen Pro (gosh, that's a mouthful of a name!) I've come to enjoy ORM a little more. Anyway, here's my question:

Say I have made a project containing the generated code and happily started using it. At some point during development some pesky user decided they want a new or modified datagrid added. If at that point I happen to need a typedlist can I just open the original L-Pro project, add the new bits that I need, and carry on?

Or a slightly different scenario: can I modify the existing classes in the generated code project through the designer?

Are the results of those two scenarios reliable?

Oh, and one more question:

Once I have generated the code and compiled it, which is the recommended practice?

1. compile the generated code and just use the .dll(s) in my solutions?
2. add the generated code projects to my solutions?

Sorry about the barrage of questions - I read through the documentation but might've missed bits

Cheers, Dany.

DanyWu wrote:

Hi everyone,

I am currently evaluating some options in Data Access Layer solutions. Thanks to Frans Bouma's post about this issue I now have some points to start with.

Having played a little bit with LLBLGen Pro (gosh, that's a mouthful of a name!) I've come to enjoy ORM a little more. Anyway, here's my question:

Say I have made a project containing the generated code and happily started using it. At some point during development some pesky user decided they want a new or modified datagrid added. If at that point I happen to need a typedlist can I just open the original L-Pro project, add the new bits that I need, and carry on?

Yes, just re-generate the code and you're set. Everything is made type safe, so even if a field name changes and you regenerate your project, re-compiling it will automatically show where you've to make changes.

Or a slightly different scenario: can I modify the existing classes in the generated code project through the designer?

Which changes do you have in mind? The generated code classes have user code regions. These regions are safe havens for your own code, i.e.: you can re-generate the project and your code added to these regions is merged with the newly generated code, so you won't lose your changes.

If you mean: renames of fields, adding/removing/hiding relations etc. : you can re-generate the code and recompile, that always works. Your OWN code can use changed elements. Though because everything is typed (and not defined with strings for example), the changes to be made (like you use C# and you changed CustomerEntity.CustomerID into CustomerEntity.CustomerId, that will break some of your code using CustomerID) are shown to you by the compiler and are easily tracked down at compile time, so no worries for runtime issues

Are the results of those two scenarios reliable?

Yes.

Oh, and one more question:

Once I have generated the code and compiled it, which is the recommended practice?

1. compile the generated code and just use the .dll(s) in my solutions?
2. add the generated code projects to my solutions?

I'd go for 1). The main reason is that VS.NET isn't that good with large solutions, and the more projects you add to your solution, the slower it works/loads and compiles. Also with more developers, sharing the generated code assemblies is easier, especially with VSS or other SCC sourcecontrol systems.

Otis wrote:

Oh, and one more question:

Once I have generated the code and compiled it, which is the recommended practice?

1. compile the generated code and just use the .dll(s) in my solutions?
2. add the generated code projects to my solutions?

I'd go for 1). The main reason is that VS.NET isn't that good with large solutions, and the more projects you add to your solution, the slower it works/loads and compiles. Also with more developers, sharing the generated code assemblies is easier, especially with VSS or other SCC sourcecontrol systems.

Amen! It's sad but true. It'd make working Code Regions much easier if one could include the generated projects in the solution, but the downsides of including them outweigh the benefits.

I haven't tried it yet, but you can create your own taskperformers to compile the generated projects and perhaps copy the assemblies to a target location. This way, it's a transparent process from Designer change through new DAL accessibility.

Jeff...

Thanks for that guys - the move away from stored procs is still a bit scary though Well, having said that, we haven't made the decision to do that just yet - still evaluating...

DanyWu wrote:

Thanks for that guys - the move away from stored procs is still a bit scary though Well, having said that, we haven't made the decision to do that just yet - still evaluating...

You can leave procs as calls in your project to make transition smoother, for some large procs you might not want to convert to C# / VB.NET code for example.