Our company is looking to purchase as OR/M and LLBLGen Pro is one of the choices that we are considering along with nHibernate and a couple other commercial solutions. We do not have an OR/M now and there are some particular questions that we have about whether LLBLGen is the correct choice.

Some facts about us and questions.

Background: Our databases are our lifeblood. Everyone says that, but we are in the Data Warehousing business. We gather information from various sources, we have a number of ETL analysts who massage the data (we have more ETL people than traditional programmers), we do a LOT of data massaging and cleanup and then our customers pay us for our reporting on that data. Our databases house hundreds of millions of records. The database model to us is of more importance than the domain model.

Question 1: Many of our updates require updating more than a single table. In some cases, this is true with 1-1 tables which are split, because we prefer database purity (i.e. we don't like NULLs). We need to be able to easily do mappings on these tables. So we might have 3 tables: Person, PersonMiddleInitial, PersonSalary that will all map to a Person object. Does LLBLGen make it easy to create all the CRUD operations for this mapping without having to write custom sprocs ourselves?

Question 2: We use a strategy of having one database per customer with identical schemas. This makes for some interesting challenges when new versions are rolled out -- our applications need to be able to support multiple versions of our schema. Does LLBLGen handle this issue?

veritas27 wrote:

Question 1: Many of our updates require updating more than a single table. In some cases, this is true with 1-1 tables which are split, because we prefer database purity (i.e. we don't like NULLs). We need to be able to easily do mappings on these tables. So we might have 3 tables: Person, PersonMiddleInitial, PersonSalary that will all map to a Person object. Does LLBLGen make it easy to create all the CRUD operations for this mapping without having to write custom sprocs ourselves?

There isn't such thing as multiple tables in one object. However you can relate all of them via 1:1 relations and save them recursively at once. For example, you could

PersonEntity myNewPerson = new PersonEntity();
myNewPerson.Name = "Veritas 27";
myNewPerson.Salary.SalaryAmount = 199000;
myNewPerson.Salary.Bonification = 500;
myNewPerson.Address.Country = "USA";
...
adapter.SaveEntity(myNewPerson, true);

veritas27 wrote:

Question 2: We use a strategy of having one database per customer with identical schemas. This makes for some interesting challenges when new versions are rolled out -- our applications need to be able to support multiple versions of our schema. Does LLBLGen handle this issue?

Well. You need to generate a new version of the generated code if a new version of the schema is released. That's expected as the generated code have mapping information. You could benefit on the fact that you could share the DAL and model domain uppon different customer apps and change its business logic.

Please let us know if you have further questions.