Help We are evaluating the use of LLBLGen Pro for use in a large project (hence the lengthly evaluation period). Using LLBL on a small project (binary remoting - SS) seems really good, very impressed. We are now looking at a test project that will generate all required classes (no additional attributes or methods - yet) and access our biggest use area (ie CRUD for the 3/4 major classes)

We have generated all the classes and tried to compile the application... Soooo slow - we have approx 500 tables and only created 4 typed lists - LLBL Gen Pro has created 2500+ cs files and to load the project takes 5-10 mins with at least 10 mins to build the DLL (P4 3Gig Processor with 1Gig RAM).

we are worried that when we add our business code to the entities and create all required TypedList this will become impossible to use....

What is the best way to manage a project of this size? Can the Generated code be broken into sub projects? We would prefer to use the SS code (seems more logical and benifical to us)

Expected Project will be 3-Tier (probably Binary Remoted) - approx 500 Tables in MS SQL Server, at least half of the tables will require a Typed List.

Any Ideas and suggestions much appreciated.

• Use adapter, it's less code and 2 projects
• Compile on the command line. This is so much faster. Please see: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=242 . Here a large project compiles under 30 seconds. In vs.net it takes aaaaaaages (if it doesn't crash vs.net)
• use a separate solution for your generated code, don't add the generated code to your own project.
• load times are high when you add your code to a VCC compatible version control system, like sourcesafe. VS.NET will then verify each file with the sourcecontrol system, which can take a long time. I suggest to use subversion or if you use Vault for example, to use Vault's Edit & Commit mode, which doesn't do VS.NET integration and therefore makes VS.NET skip teh verification process on load. With subversion, you can create a simple .cmd file which first updates the code from the repository to get the latest updates, then opens vs.net and loads the solution.

Typedlists, typedviews and stored procedures can be placed in another vs.net project, though keeping the same rootnamespace. You then reference in the typedlist/typedview project the entity project (compiled form). You can select which elements to generate in a generation cycle, in the generator configuration dialog.

Thanks. There is no source control intervention happening - we have not yet integrated the Source Control and the IDE I would prefer to avoid the adapter if possible - I just don't see the benefits... To me it appears that I lose out on the code generation of the Entity objects that I will be adding lots of code to (ok I can create the descended entity objects - but that is losing benefit!) it also moves away from (which seems so logical) the objects doing the required work - the adapter does the work. We are looking at Creating and filling objects in the AppServer then sending the object (by value) to the client - the user then works with the object and when finished sends the object back to the AppServer - the AppServer then does the required persistence (Save Delete etc). This may seem an overly simple approach - but I want to have this as simple as possible (only add complexity if the is a definite benefit). The application will be, once complete, under constraint maintenance/upgrades - the nature of this type of application!

I like the idea of splitting out the typed lists - better yet, is it possible to split out the Entity objects (leaving the EntityBase objects and the rest of the generated code in one project) and have the Entity objects, which will contain out business logic, in a separate project ?

I hope this doesn't seem too muddled - we are new to C#, ORM's and LLBLGen-Pro.

PaulMckenzie wrote:

We are looking at Creating and filling objects in the AppServer then sending the object (by value) to the client - the user then works with the object and when finished sends the object back to the AppServer - the AppServer then does the required persistence (Save Delete etc).

Additional food for thought: Adapter vs. Self Servicing when using remoting

• Adapter model generates a much smaller code set
• Adapter Entity Objects don't carry the persistance logic; better performance when using remoting
• Adapter persistance logic can remain in your AppServer where it is needed; guarantees client code can't persist data

*  Adapter model generates a much smaller code set

The Adapter generates smaller code but I have to create descendant objects for each Entity... * Adapter Entity Objects don't carry the persistance logic; better performance when using remoting Hadn't thought of that - shouldnt be mush overhead though - or is there? * Adapter persistance logic can remain in your AppServer where it is needed; guarantees client code can't persist data Client can't pesist anyway - no DB connection.

The adapter (IMHO) just seems more work and an odd way of thinking to me... The object is the "thing" that should perform all data operations.

PaulMckenzie wrote:

*  Adapter model generates a much smaller code set

The Adapter generates smaller code but I have to create descendant objects for each Entity...

There are templates available for adapter which generate per entity a derived entity class for your code. You can also add your code to user code regions in the entity classes OR (preferably) add your code to include templates you use to generate the code into the generated classes.

* Adapter Entity Objects don't carry the persistance logic; better performance when using remoting

Hadn't thought of that - shouldnt be mush overhead though - or is there?

This is indeed not that important for the overhead, though it is important for the delegation of responsibility: an entity on the client shouldn't have Save, Delete etc. as it can't reach a db. What's also a problem with selfservicing in remoted scenario's: lazy loading. If you send back a customer entity and on the client you touch customer.Orders, you'll get an exception, as it can't load Orders.

There is some extra overhead in selfservicing entities: they carry their persistence information with them, and in adapter that's not the case, so remoting will be less efficient with selfservicing.

* Adapter persistance logic can remain in your AppServer where it is needed; guarantees client code can't persist data

Client can't pesist anyway - no DB connection.

Though it will lead to runtime errors and you can't separate the functionality very clearly. THough it's of course up to you .

The adapter (IMHO) just seems more work and an odd way of thinking to me... The object is the "thing" that should perform all data operations.

I understand that POV, it is why selfservicing exists . Though after a while, users started to request a more remoting friendly setup, where the entities weren't packed with persistence information and -functionality, hence adapter was added for this purpose. After a short while, adapter will feel as logical as other code.

I like the idea of splitting out the typed lists - better yet, is it possible to split out the Entity objects (leaving the EntityBase objects and the rest of the generated code in one project) and have the Entity objects, which will contain out business logic, in a separate project ?

Yes you can do that. If you take a look at the file TwoClassScenarioFull2003.config in the Taskperformers folder in the llblgen pro installation folder, (open it in a text editor, it's XML), you'll see task definitions in a hierarchical format. If you then take a look at the AdapterScenarionFullSafe2003.config, you'll see it has 2 vs.net project tasks instead of one. You can freely move around the tasks, define new ones and for example create a selfservicing generator config which creates 2 projects instead of 1: one with the regular code and one with the derived entities. You can also create 3 for example, one for the regular code, one for the derived entity classes and one for the typedlist/typedview and procs. That last one requires an updated constantsEnums.template so the typedlist/typedview enums are not generated in the project where the entities live etc.

As you're evaluating, you don't have access to the SDK docs. I can send you the .chm of the SDK so you can learn more about the structure of the templates and generator configs so you can make the proper adjustments to see if you can set it up the way you want it.

Thanks... I did not realise even accessing an entity would cause an exception!

You mentioned templates available for adapter which generate per entity a derived entity class for your code, is it possible to have the Adaptor Scenario generate 3 project. DB Specific Project, Base code project, and a project with the derived entities and TypedList classes ? I would go for this... We are in the final evaluation doing some "what can it do" tests - BTW we have now purchased LLBL

Accessing an entity will only cause an exception if the PrefetchPath has not been executed - Not accessing the field itself when an Entity does not exist (not too different to trying to access a non created object).

I have been looking into Templates - non-trivial... If we had time and a greater understanding of LLBL etc... maybe but at the moment I do not wish to launch into creating/modifying templates which we will then have to debug maintain - especially when migrating to v2.0 etc...

One major cause of the slowness we have discovered - The Borland IDE. We have dropped the Borland C# IDE and are now using the MS VS 2005 IDE... Wow. Loads immediately (opposed to 2-3 minutes to load empty - no projects). Build time is approximately half that of Borlands and the background build allows interaction with files.

I would still like to be able to use the SS Style but split off the Entity and TypedList objects to a seperate project - but only if I do not need to spend time both now and in the future. It looks like to split them off I would need to spend time now and in the future for maintenance.

PaulMckenzie wrote:

Thanks... I did not realise even accessing an entity would cause an exception!

Only if you touch a property which triggers lazy loading of course . But because this is transparent, you can run into this at runtime, which might cause delays and slowdowns.

You mentioned templates available for adapter which generate per entity a derived entity class for your code, is it possible to have the Adaptor Scenario generate 3 project. DB Specific Project, Base code project, and a project with the derived entities and TypedList classes ? I would go for this... We are in the final evaluation doing some "what can it do" tests - BTW we have now purchased LLBL

The derived entity templates are called 'Extended entity generator templates for Adapter', in the 3rd party section.

PaulMckenzie wrote:

Accessing an entity will only cause an exception if the PrefetchPath has not been executed - Not accessing the field itself when an Entity does not exist (not too different to trying to access a non created object).

Or when you call Save/Delete.. But that's trivial, as long as you keep an eye on that, that you need to call the service / BL instead of calling the methods in the PL.

I have been looking into Templates - non-trivial... If we had time and a greater understanding of LLBL etc... maybe but at the moment I do not wish to launch into creating/modifying templates which we will then have to debug maintain - especially when migrating to v2.0 etc...

The modification of the generator config files (which means: make a copy of the one you want to alter, change the <name></name> contents to distinguish it from the rest, and then alter the tasks / add/remove tasks ) is pretty straight forward. The SDK has in depth documentation about what the tags mean and there aren't that much tags so it's pretty easy.

To create a second vs.net project in a generator config file, you need to use the way it's done in the Adapter generator config files. If you take a look at those, you'll see how it's done, it's pretty easy.

Though I can understand why you are now reluctant to alter them right away. You can alter them later on, if you'd like.

One major cause of the slowness we have discovered - The Borland IDE. We have dropped the Borland C# IDE and are now using the MS VS 2005 IDE... Wow. Loads immediately (opposed to 2-3 minutes to load empty - no projects). Build time is approximately half that of Borlands and the background build allows interaction with files.

I tried it once and found it a step back from VS.NET, even though it was newer. Missed chance for borland.

I would still like to be able to use the SS Style but split off the Entity and TypedList objects to a seperate project - but only if I do not need to spend time both now and in the future. It looks like to split them off I would need to spend time now and in the future for maintenance.

True, but only when upgrades are released. You can wait for the 1.0.2005.1 upgrade and use that codebase to start splitting the projects. (It's a month or so away) so you have some more experience with the various system elements.

We are now working in VS2005 Beta2 - Wow ... what a speed improvement over the Borland IDE! The speed is now acceptable, and should be even better in the next release. We have found the SS Generated project not too bad to use in VS2005 - I wouldnt' try this in Borland IDE though We will be upgrading to the 2005 version as soon as it moves to release - same with the .Net 2 version (even if a bit of recode required) assuming it is in the not too distant future. Because of this and tight deadlines we will not look at modifying the templates or generator config files.

in the 1.0.2005.1 version I managed to bring down the amount of code for selfservicing to some degree. Removed unnecessary fluff, and moved code from collection classes to the base class, and made the DAO classes very small. It should be an improvement. The speed optimizations I made to the adapter serialization are also significant. Selfservicing isn't optimized because it carries along more information per entity, namely the persistence info, and it was no real optimization benefit there. I also didn't optimize it because selfservicing isn't recommended in remoting scenario's.

I never thought Borland's IDE was that bad though... glad I didn't move to borland's IDE some time ago when I was tired of vs.net

The Borland IDE was our initial choise because we were a Delphi shop. Neither the current Borland IDE (Delphi2005) or the next, due out in Nov2005 (Delphi2006) are .Net 2.0!

The Speed and size improvements sound great... I am reluctant to move to the Adaptor due to the benefits provided by SS! all the typing and pre descended Entities etc.