We are currently in the process of moving from Self-Servicing templates across to Adapter templates (to allow us to enforce a truer MVC design pattern). We are trying to establish the best way to configure LLBLGen so the code generates into the namespaces and projects as we would like...

Here is what we are attempting to achieve:

Business Layer Ideally, we would like the Database Generic code to generate into a project with the name (and namespace, and physical directory) "Business". As the name suggests, this would contain all the business logic for the application.

By having the Database Generic code and the Business Logic share the same project, it allows the entities to be extended with custom Business layer objects, as well as the Business layer objects being able to use the entities. (This would not be possible unless the projects were shared - as circular project references are not allowed).

DataAccess Layer We would like the Database Specific layer to generate into its own folder (and project, and namespace) so as to cleanly separate it from the business layer. The business layer can then reference this, so that it can access the database Adapter code as needed.

Question Is there any way to configure LLBL to generate as above – or is there a good reason that it shouldn’t? Looking it the current options available, it seems that it is only possible to generate the database specific and the database generic code into subdirectories of the same folder (and have the same root namespace). This may be a workable solution, but we would like to try to avoid it, as it would result in the Database Specific code being part of the Business namespace, which conceptually I don’t think it should be.

Any advice appreciated

Summarizing your requirements is that you need a way to define TWO namespaces (instead of ONE) and designate TWO output folders (instead of ONE).

First of all, you need to create your own VS.NET project template(s) based on that used by LLBL's.

Then you need to define custom named-properties for the LLBL designer project. These properies namely define your BL's project namespace and BL project's output folder.

Then you need a custom LLBL task-performer to be used by the code-gen process. The role of this task-performer is to reference the named custom-properties and use their values for BL's namespace and output folder (ofcours ethis means that you need to standardize the name of these properties).

We are using this approach in the JCL framework. In JCL, I have a BL project template that needs to be generated in its own folder and have its own namespace.

Some how similar questions: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=4423 http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=5169 http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=9422

Thanks for the responses - they were very helpful.

I would be interested to hear how others structure their Adapter template projects. It seems that currently a fair amount of work is required to allow the code to generate so that the db generic and the db specific code are in separate namespaces and locations (such as the db generic code to generate into a "Business" namespace/location/project, and the db specific code into a "DataAccess" namespace/location/project). This seems to restrict the ability for Entities to be extended with custom Business code... or am I missing the point? Any input welcome

In the thread: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=4423 Otis mentioned that it was in future plans to extend the designer to allow different root folders to be specified for the database generic code, and the database specific code? Is this still in the future plans? Any idea when? I think this would be a great addition, as it would allow users to structure their projects as they wish "out of the box" - without having to edit templates.

Check v2.5 beta . Load a project, press F7 go to tab 3 of the generator config to view the queue. Then click on any task group. Et voila! rootnamespace and rootfolder fragment specifications per task group are specifyable

Wow - that's great! Thanks