We have a database driven application where most of the Business Logic is in stored procedures. We are using LLBLGEN Pro to create a new DAL and eventually start using ORM features as needed.

The problem I seem to have is that even though you can group stored procedures, the generated code puts all the procs on one file and not use namespaces for the groups. The other option is to create different projects per group but that would break our ability to use ORM in the future.

Is there a way to generate one project that contains the procs and separate them via namespaces?

I would hate to have 20 projects to do something like this.

Thanks in advance.

Hi, this is not currently supported. Let us check whether or not this is something considered in future versions.

Namespace control is planned for a future version, but it's not as simple as placing things in namespaces, as it has far reaching consequences, as for e.g. entities it means referring code has to work with the namespaces as well. For stored procedures, would that mean a file per namespace or 1 file with all the namespaces?

Otis wrote:

Namespace control is planned for a future version, but it's not as simple as placing things in namespaces, as it has far reaching consequences, as for e.g. entities it means referring code has to work with the namespaces as well. For stored procedures, would that mean a file per namespace or 1 file with all the namespaces?

I like the way Resharper recommends naming conventions based on folder structure.

project - Students (folder) - Student.cs (namespace: projects.Students.Student)

Personally my goal with LLBLGEN is to generate the code and forget about it. But right now accessing my over 1k storedprocs in one file makes it a pain on the BL to access the procs.

I mean when I'm working on my student object and type Dal.DatabaseSpecific.RetrievalProcedures.??? The massive list is a pain especially if the db admin didn't name them in a way that makes sense. Which sadly I don't have any control over it.

Since I have to point to the database specific folder for procs, It would be nice to have some structure there as well.

So in my case having multiple files or folders or one file for namespaces is not an issue for me since my goal is not to touch the generated code.

Thanks for the input, and I agree it is a pain in your situation. I don't have a turn-key solution for you at this point however. We'll take your feedback into account when triaging the features we should implement in the versions to come. As said, it's not as simple as adding a couple of statements, but perhaps we can find a middle ground somewhere. It's not available tomorrow, so sadly, I can't help you with a quick solution.

If it really bothers you, the only thing to do here, I think, is creating copies of the templates used and generate your own versions from them to emit the namespaces (e.g. generate the namespace <groupname> { ... list of procs }

blocks in the same file as the code is stored now. But as said, it's not as simple as it looks.