Generated code

This section enlists some of the best practices for the generated code, produced by LLBLGen Pro's code generator engine. Using these best practices will give you better results with LLBLGen Pro.

  • Read the 'using the generated code' documentation. The section about using the generated code is really useful to get started and to get informed how to achieve things with the generated code. Skipping that section can leave you in the dark for a long time how to use the generated code in full.
  • Use the LLBLGen Pro reference manual or generate one on your own. The generated code contains detailed information about its functionality in the form of code comments which are modified to your project's code. It is still wise to look up methods in the shipped LLBLGen Pro reference manual which also contains the reference manual for the ORM support classes. The LLBLGen Pro reference manual gives you detailed insight in what a method does, what a given property does and what their purposes are.
  • Use the generated Visual Studio project files. The presets shipped with LLBLGen Pro to generate code will generate a Visual Studio.NET project file (or files, if more projects are required) for you when you generate code. It depends on the target platform, e.g. .NET 4.0 or .NET 3.5, for which version of Visual Studio the project file is meant. It is recommended to use these Visual Studio project files as they already contains the right references and all the files in the project. A Visual Studio project file is never overwritten but updated every next time you generate code.
  • Add the contents of the App.config file to your executable/webproject's .config file. LLBLGen Pro generates an App.config file which contents should be added to your project's own .config file, for example the app.config file of your winforms application or the web.config file of your webapplication. You should add the key tag defined in the appSettings tag in the generated App.config file to the appSettings tag in the config file of that executable project (for example the web.config file of your ASP.NET project).
  • Cache results of object usage, not the object itself. Because entities are stored in the persistent storage that is shared by all the threads in your application (or by all clients that target the same database), it is wise to keep the persistent storage up to date with changes so other threads can see these changes. When you cache objects in memory for a longer period of time, the entity data in the cached object can get out of sync with the entity data in the persistent storage (i.o.w.: get stale). It's better to cache the results of entity data processing than to cache the entity data itself: when you process an entity to create a piece of HTML, cache that HTML using ASP.NET's cache services (for example for 10 minutes), instead of the entity which produced that HTML. This way you save even more performance, because you don't have to re-process the entity.
  • Call DataAccessAdapter.Dispose() if possible. On Oracle and Firebird, it's key to call DataAccessAdapter.Dispose() after you're done with using a DataAccessAdapter instance. It's best to use the using statement in C# and VB.NET, which calls Dispose() for you, like in the following example: 
    using(var adapter = new DataAccessAdapter())
{
    adapter.FetchEntityCollection(myCustomers, null);
}
  • Choose database filters over in-memory filters. If you have the choice between in-memory filters using EntityView(2) objects, or filters on the same data in the database, it's best to opt for the latter, as that means less data is pulled into memory and less processing has to be done by your application. It might be of course your application can spare the processor time and your database system can't, so at least perform research which option is the most appropriate in a given situation.