Hi,

I am going to be evaluating LLBLGen for a project that's early in development. I've looked at .netTiers before but my initial impression is that I really like LLBLGen's dynamic nature instead of massive amounts of SPs.

I'm just starting to go through the demo and the documentation, but I have some nagging questions that I hope someone can clarify for me before I delve too deeply:

1) The application is ASP.NET based so we plan to use timestamp based "record locking" (where every table has a timestamp field, and a record that is loaded into a custom entity cannot be saved back to the database if the current timestamp has changed since it was loaded into the entity. And, in that event, the current transaction would fail as well). Does LLBLGen handle this natively? If not, can I add this code in a logical place within the generated code? If not, how do other people deal with web based record locking.

2) Our database is fairly large. For manageability, I want to have multiple projects, each containing the BLL and DAL for logical subsets of the database tables, instead of one massive project with many hundreds of classes. Can LLBLGen accomodate this? ie, can I instruct LLBLGen as to which tables should be in this project and which should be in that project? And in the cases where there is business logic crosstalk between the two projects, any problems with referencing and using other projects in the entities?

I do see that I can create an LLBLGen project and then select the tables I want included, but I wanted some feedback on the practicality of extending that to multiple projects, each with a subset of the database tables.

3) I will be using schemas in my table naming convention (when I say schema, I am referring to the SQL Server 2005 feature which allows you to grant ownership of your table to a schema such as Production.TableName instead of dbo.TableName). Does LLBLGen qualify table names with its schema name for best performance? Does it do anything else with the schema name as far as using the schema name in its entity naming conventions?

Thanks,

Cory

benjam47 wrote:

1) The application is ASP.NET based so we plan to use timestamp based "record locking" (where every table has a timestamp field, and a record that is loaded into a custom entity cannot be saved back to the database if the current timestamp has changed since it was loaded into the entity. And, in that event, the current transaction would fail as well). Does LLBLGen handle this natively? If not, can I add this code in a logical place within the generated code? If not, how do other people deal with web based record locking.

LLBLGenPro offers Concurrency Control through IConcurrencyPredicateFactory objects. Is very easy to use. You can send it in a update action directly or inject the property directly through dependency injection. (Ref: LLBLGenPro Help - Using the generated code (Adapter or SelfServicing) - Using the entity classes - Concurrency control).

benjam47 wrote:

2) Our database is fairly large. For manageability, I want to have multiple projects, each containing the BLL and DAL for logical subsets of the database tables, instead of one massive project with many hundreds of classes. Can LLBLGen accomodate this? ie, can I instruct LLBLGen as to which tables should be in this project and which should be in that project? And in the cases where there is business logic crosstalk between the two projects, any problems with referencing and using other projects in the entities?

You can create multiple projects targeting different database objects so you can specialize your DAL/BLL. You can reference the generated projects (assemblies) in any other projects.

benjam47 wrote:

I do see that I can create an LLBLGen project and then select the tables I want included, but I wanted some feedback on the practicality of extending that to multiple projects, each with a subset of the database tables.

Well, that depends upon the size of your project. When the project is very large and other programmers work on different business section is good advice to split and manage different projects. Anyway, there are people managing large databases in a single LLBLGen project and everything ok so far.

benjam47 wrote:

3) I will be using schemas in my table naming convention (when I say schema, I am referring to the SQL Server 2005 feature which allows you to grant ownership of your table to a schema such as Production.TableName instead of dbo.TableName). Does LLBLGen qualify table names with its schema name for best performance? Does it do anything else with the schema name as far as using the schema name in its entity naming conventions?

As far as I know that isn't possible. But you can create different projects and target them to different Root Namespaces (MyCompany.ProductsScope.ProductEntity, MyCompany.ContactManager.Person, etc.).

Please let us know if you have further questions.

Some additional info to what David said

benjam47 wrote:

Hi, 2) Our database is fairly large. For manageability, I want to have multiple projects, each containing the BLL and DAL for logical subsets of the database tables, instead of one massive project with many hundreds of classes. Can LLBLGen accomodate this? ie, can I instruct LLBLGen as to which tables should be in this project and which should be in that project? And in the cases where there is business logic crosstalk between the two projects, any problems with referencing and using other projects in the entities?

LLBLGen Pro is used by teams with thousands of entities, so it's usable, though in general I'd go with what David advised.

3) I will be using schemas in my table naming convention (when I say schema, I am referring to the SQL Server 2005 feature which allows you to grant ownership of your table to a schema such as Production.TableName instead of dbo.TableName). Does LLBLGen qualify table names with its schema name for best performance? Does it do anything else with the schema name as far as using the schema name in its entity naming conventions?

It specifies tables with catalog AND schemaname. so you can have multiple catalogs in 1 project and create relations between entities inside all these catalogs (so across catalogs) and join them together at runtime. You can also overwrite these schema/catalog names at runtime if you want to use different schemas/catalog names. Please switch on Tracing (Using the generated code -> Troubleshooting and debugging ) to see what queries are generated