Greetings All,

First, I have a confession to make. I am a VB developer. I hope this doesn’t mean that I will be frowned upon, after-all under the .NET CLR “C# is just VB with semi-colons and VB is just C# without semi-colons” ... Rockford Lhotka Now, if you carried on reading a post from a VB developer preaching best practices for a community of top notch C# developers then you should really give yourself credit as being open minded (just last week if somebody came-up to me and told me that stored procedures where NOT the way to go, I would laughed him out my office ? )

I have been evaluating LLBLGen for less than a week now, and I felt that I had to compile a list of guidelines or best practices for integrating LLBLGen in our development cycle. I am not new to the concept of using code-gen tools but I am starting to see LLBLGen as an integral development tool. After watching the tutorial videos (excellent work), reading LLBLGen’s help file and studying the example projects, I came up with the following list of guidelines and questions:

Database design: - all tables should have primary keys (PK) - define relationships between all tables to enforce referential integrity. This should be the case for child tables (Order-OrderDetails) and lookup tables (Customer table with a nullable field “area” and the Area table) - all unique constraints should be build as constraints and NOT indexes questions: When should we use stored-procedures (if any)? questions: What’s the difference between building a view (resulting a TypedView) and building a TypedList from LLBL’s designer?

Directory Structure:_for a hypothetical HR application_ HR folder (contains solution and project folders) HR folder (contains HR UI project) GeneratedCode folder (containes generated project(s) from LLBLGen) LLBLGenProjects folder (contains LLBLGen projects) questions: Where to code the business logic for an entity class (Employee); in the Entity class itself or should I create a manager class for that purpose? If a manager class is to be created then should I create a seperate prject for it or should it be part of the (HR.DAL) project?

LLBLGen & UI: questions: are there any plans to extend the functionality of LLBLGen so that it would generate WinForms and/or ASP.NET UI projects (what I'm really asking here is if Frans has plans for a UI framewrok (WinForms and/or ASP.NET) that best utilizes LLBLGen's DAL code)?

I hope that veteran LLBLGen users be generous enough to share some of their best learned lessons in building both WinForms and ASP.NET solutions..

Omar

omar wrote:

Greetings All,

First, I have a confession to make. I am a VB developer. I hope this doesn’t mean that I will be frowned upon, after-all under the .NET CLR “C# is just VB with semi-colons and VB is just C# without semi-colons” ... Rockford Lhotka

VB developers are just as welcome as C# developers.

I have been evaluating LLBLGen for less than a week now, and I felt that I had to compile a list of guidelines or best practices for integrating LLBLGen in our development cycle. I am not new to the concept of using code-gen tools but I am starting to see LLBLGen as an integral development tool. After watching the tutorial videos (excellent work), reading LLBLGen’s help file and studying the example projects, I came up with the following list of guidelines and questions:

Database design: - define relationships between all tables to enforce referential integrity. This should be the case for child tables (Order-OrderDetails) and lookup tables (Customer table with a nullable field “area” and the Area table)

You don't really have to do this of course, but it's easier. You can also create relations in the designer.

questions: When should we use stored-procedures (if any)?

Use stored procedures for processing of large amounts of data. If you have to process 1 million rows, it's perhaps more efficient to program the logic in a stored procedure and call that from your BL than to read all those 1 million rows into objects, process them and save them again. But it also depends on what kind of processing has to be performed.

questions: What’s the difference between building a view (resulting a TypedView) and building a TypedList from LLBL’s designer?

The designer for the typed list doesn't allow you (yet, will come later this year) to add expression columns and other nice SQL constructs, a view does.

Directory Structure:_for a hypothetical HR application_ HR folder (contains solution and project folders) HR folder (contains HR UI project) GeneratedCode folder (containes generated project(s) from LLBLGen) LLBLGenProjects folder (contains LLBLGen projects) questions: Where to code the business logic for an entity class (Employee); in the Entity class itself or should I create a manager class for that purpose? If a manager class is to be created then should I create a seperate prject for it or should it be part of the (HR.DAL) project?

It's how you want to look at data: domain model (BL in entity classes) vs. the entity model with entities without behavior, which have the bl logic in classes which are modeled after the process they represent. These classes are created in a separete project.

LLBLGen & UI: questions: are there any plans to extend the functionality of LLBLGen so that it would generate WinForms and/or ASP.NET UI projects (what I'm really asking here is if Frans has plans for a UI framewrok (WinForms and/or ASP.NET) that best utilizes LLBLGen's DAL code)?

Yes, gui templates are in the works, as well as a template editor for the new C#/VB.NET asp-style template engine.