Hello,

We are using LLBLGen to create the data access layer for a very large data centric application. We use SqlServer with multiple Databases per server instance. There are several servers but they all have the same overall schema.

Conceptually we will treat the system as a single database with multiple schemas. LLBLGen handles this very well. However, we will end up with over 1200 tables and views. I would like any design/architecture suggestions or concerns on using LLBLGen with such a large entity set.

As it stands we intend to use the Adapter templates with single project for all entities. I have two primary concerns: performance and namespace granularity.

Performance How will the size of the entityset affect performance. (Factory classes, enumerations, run time reflection ...)

Namespace Granularity Clearly 1000+ classes are too many for a single namespace. I would like to organize the entities in multiple namespaces. How do I go about doing this? I see that all entities in a project need to be listed in an enum and share factory and helper classes. I think that we can work within this context by ensuring that all entity classes have unique names. Are there other limitations?

thanks in advance

Nick

I don't think there will be any performance issues in using large number of entities. We have customers who have used such big schemas.

As for the Namespace issue, I'll just quote Frans words here:

Frans wrote:

The grouping per namespace is a request that's been made a couple of times and we also tried to implement it a couple of times. The main thing that kept it from being a feature was that it turned out to lead to completely separate projects: A generated project has one EntityType enum, it has one set of factories etc.

To group entities in different namespaces, with potentially entities with the same name, it would mean that these groups would need their own entitytype and their own set of factories. So that meant in effect, per group of entities a separate project being generated.

I'd create multiple projects if the # of classes is too big. Often in these large schemas, it's not hard to recognize the different subsystems which aren't related. So in other words: it's unlikely you have a fully connected entity model of 1200 entities so you can traverse from any entity to any other entity in that 1200 entities.

Another tip: with large schemas, compile code on the command line: it's much faster. Reference the generated code as an assembly in your own project. This way vs.net isn't bogged down by the code.

Hi, thanks for the response.

I spent a bunch of time over the weekend trying to figure out how to break up the system into multiple data subsets (one for each project). Unfortunately, it is proving to be extremely difficult as there are a good number entities that permuate acrross all subsets. I also lack the knowledge to properly organize the existing tables as well as the time to attain it.

Due to our required client response time (less than a week for new data access requests) as well as political and training related issues, the success of my effort will heavily depend on (a) minimizing the learning curve for developers, (b) minimizing the time it takes to build and use the DAL layer and (c) minimize the risk that future framework enhancements will require code changes to existing modules.

For these reasons I have come to the conclusion that our DAL framework must be built around a single LLBLGen project and relly on namespaces to organize the entities based on the current database schema. For example, I would like to map table Common.dbo.geoCounry to a namespace equivalent of Company.Dal.Common.Geography.Country.

First, my apologies for being so verbose . I am in process of going through the templates to identifiy the changes I will have to make and to support namespaces and would appreciate any input or existing code you can provide .

Thanks again,

Nick

nfoscolos wrote:

Hi, thanks for the response.

I spent a bunch of time over the weekend trying to figure out how to break up the system into multiple data subsets (one for each project). Unfortunately, it is proving to be extremely difficult as there are a good number entities that permuate acrross all subsets. I also lack the knowledge to properly organize the existing tables as well as the time to attain it.

It's not important if you share an entity in 2 projects. For example, if you save the entity in one project and use it as a readonly lookup entity in another, it's perfectly fine to share an entity in both.