Hi,

We have been using LLBL now for sometime and would never consider not using it. Most of our projects are quite small so we don't normally encounter large database schemas. But for one of our projects we are using selfservicing on a database that has 50ish tables. The dll when compiled is about 3.8mb, is this a good size?

We use JetBrains Resharper which is also an excellent tool, but it really doesn't like this project, nor does VS.net the intellisense is really slow for both when building Predicates (there are 50ish EntityFieldIndexs to choose from).

So really what sort of sized databases are you guys using?

One of my old employees use to work for Ford and their web portal database had 800 tables, would LLBL deal with this, or would it be advisable to break the project down into small projects?

Cheers

Gareth

ReSharper is a cool tool - but it really does suffer with performance problems. I've had to stop using it on my desktop, it eats up to much memeory, which is a shame because it really used to help me out. Also - its intellisense used to just crahs my laptop - not very productive for me !!!

The problem with ReSharper is that it tried to pre-load all method overloads, and after a few it really starts to struggle.

I think the point I'm trying to make is that its not LLBLGen-generated code that is a problem with ReSharper, its the other way round

GarethBrown wrote:

Hi,

We have been using LLBL now for sometime and would never consider not using it. Most of our projects are quite small so we don't normally encounter large database schemas. But for one of our projects we are using selfservicing on a database that has 50ish tables. The dll when compiled is about 3.8mb, is this a good size?

SelfServicing gets more heavier on teh code size than adapter, though code is not that much of a concern, as it is shared among all live objects in memory.

The largest class is often the predicatefactory. Current templates rely on it in some area's and I've removed these references in the upgrade coming soon. This means that if the project gets too large, the developer can opt for removing the predicate factory from the project and use Field*Predicate classes instead. (or add it to another project)

There are customers with projects with over 2000 tables. The designer's project explorer gets a bit sluggish, I've tried to address that in the upgrade coming soon.

We use JetBrains Resharper which is also an excellent tool, but it really doesn't like this project, nor does VS.net the intellisense is really slow for both when building Predicates (there are 50ish EntityFieldIndexs to choose from).

So really what sort of sized databases are you guys using?

I've tried resharper but it doesn't like large projects. The project explorer class and the mainform class in llblgen pro's designer for example are not that small (largely event handling code which calls into the middle tier objects, but still massive). It was so slow, I had to remove resharper.

Intellisense can get slower, but with 50 or so enums it shouldn't be slow. The CMS which runs llblgen.com has over 80 tables but writing the viewer for asp.net using llblgen pro code wasn't a problem.

One of my old employees use to work for Ford and their web portal database had 800 tables, would LLBL deal with this, or would it be advisable to break the project down into small projects?

It will result in a lot of code, at least over 800 entity classes. But the main problem is the predicatefactory class, which generates per entity a couple of methods. With a lot of tables, you can end up with a class with thousands of lines of code. As it is a helper class, it should be possible to remove it from the project to save space. The upgrade, which goes in beta hopefully this week, doesn't rely in the predicate factory anymore. Also custom properties eat up a lot of space if you have enabled them.

With large projects, if code size is a concern, I'd opt for adapter. The code is smaller.

Thanks.

We have now swapped over to Adapter, for all new projects and I can see there is a decrease in code and dll size.

Resharper 1.5 came out this week and i must admit it seems to preforming a little better. As I have said before I'm looking forward to the upgrade...

Is code size really a problem. If so can you list a few reasons why it is a problem. I personally like Self servicing. So i am trying to find the reasons. Thanks.

netLearner wrote:

Is code size really a problem. If so can you list a few reasons why it is a problem. I personally like Self servicing. So i am trying to find the reasons. Thanks.

It's mainly vs.net related. A project with over a 1000 tables generates in selfservicing around 3500 classes, which can be too much for vs.net when you want to compile it in there (compile it on the command line, works fine). Intellisense is not that solid either so it can stop functioning or take a long time if you have a lot of types. I'm not sure if this differs from vb.net and C#, but I think it does, as vb.net does background compilation, which can eat more resources during development.