Long Winded Background (sorry ) A conviction that I've developed over the last 10 years in the industry is the importance of creating and consistently employing accurate metaphors in the design process. I’m not suggesting that metaphors are silver bullets to achieve quality software or anything as radical as that. That said, in my experience, the right metaphors go a long way in perpetuating the overall vision for a project while the wrong metaphors can contribute to confusion in the best case and poor design choices in the worst case.

Many of us use the Tier metaphor in the design process and one of the ways we implement the metaphor is through naming conventions for our assemblies and namespaces.

I'm using the adapter model employed by LLBLGen Pro and after a lot of thought I've started to see the DB specific code as a part of the DAL and the generic code as part of the BLL. The details of interacting with the data store directly and moving data in and out of entities is what the DB specific code and the DQE's are all about (as I understand it) so, conceptually, I see them as part of the DAL. On the other hand, the entities that are a part of the generic code generated for adapter seem totally wired for the BLL.

The Actual Questions This brings me to my 2 questions for all of you.

I'd like to implement this Tier metaphor through the assembly/namespace names of the 2 projects of the adapter code in the following way...

<Company>.<Product>.Core (generic code) <Company>.<Product>.Data.<Database> (database specific code)

We use 'Core' as the suffix for BLL assemblies and 'Data' as the suffix for DAL assemblies.

Question 1: After reading through the forums I found some posts on this issue but it really wasn't clear to me from them exactly how I could achieve the above. As I see it, the key impediment is the fact that the project properties in LLBLGen Pro provide a way to specify a DB specific suffix but no way to specify a suffix for the generic code.

Question 2: The entities in the generic code offer so much goodness for the presentation tier in the form of implementations for IBindingList, IEditableObject, save points for field data, etc. However, I've already had several occasions where I need to create a BLL class that's a hybrid of one or more entities. I'd like these hybrid BLL classes to be able to have the same goodness that the entities have w/o having to code it all from scratch. Is there a way to leverage the goodness in the entities in my custom BLL classes w/o re-inventing the wheel so-to-speak?

Hi,

Q1: as you noticed, you can't do that from the designer. Now this is because the generic code actually uses several more namespace suffixes. Now if you want to enforce a constant "core" suffix, you may just update the templates, cause anyway that's what changing it would require -> replace <[RootNamespace]> with <[RootNamespace]>.Core in all your shared templates. and use Data as the dbspecific namespace.

Q2: Inheritence and contained entities as properties should let you be able to leverage existing entities. Maybe an entity based on a view combining the targeted tables can do the trick, if you want to combine them flat. Now I'm not sure to understand exactly what you're looking for.

Jessynoo wrote:

Hi,

Q1: as you noticed, you can't do that from the designer. Now this is because the generic code actually uses several more namespace suffixes. Now if you want to enforce a constant "core" suffix, you may just update the templates, cause anyway that's what changing it would require -> replace <[RootNamespace]> with <[RootNamespace]>.Core in all your shared templates. and use Data as the dbspecific namespace.

Q2: Inheritence and contained entities as properties should let you be able to leverage existing entities. Maybe an entity based on a view combining the targeted tables can do the trick, if you want to combine them flat. Now I'm not sure to understand exactly what you're looking for.

thanks for the response...

Q1 I'm not sure I understand the limitation you describe in reference to Q1. It sounds like you may be saying that there's a technical impediment but I only see a design [choice]/[side effect] to exclude support for a namespace suffix in the case of the generic code. I'm assuming if it was ever officially implemented as part of the designer/generator it would work a lot like the implementation of the DB specific suffix (maybe that assumption is bogus though). I mean, I realize that there are lots of references to <[RootNamespace]> in using/imports statements where something follows after <[RootNamespace]>. e.g.

using <[RootNamespace]>.HelperClasses;

But couldn't something like the following work just as well?

using <[RootNamespace]><[DbGenericNamespaceSuffix]>.HelperClasses; 

Q2 That's a great point on the views although one scenario that I’m working in is really constricted as far as the schema changes I can make. Would it be possible to go into more detail on how to leverage some of the LLBLGen Pro generated entity goodness for non-LLBLGen Pro generated BLL classes?

Would you please elaborate more on Q2?

Thanks.

If you want a different namespace for the generic classes, you could opt for generating two times: one for the generic classes and one for the dbspecific classes. You can do this from the command line, using the CLI generator (Which is in the SDK). You could create a small .cmd/.bat file which generates the code for you properly with the appropriate namespaces. Use 2 folders for the two outputs, and in your solution you reference the generic project from one folder and the dbspecific project from the other.

The option isn't added as the requirement is pretty rare

Walaa wrote:

Would you please elaborate more on Q2?

Thanks.

Thanks for the response

Based on the responses I've gotten so far (by no means a criticism) it seems like I must be coming at this quite a bit differently that most folks so maybe I shouldn't waste any more of anyone's time.

Otis wrote:

If you want a different namespace for the generic classes, you could opt for generating two times: one for the generic classes and one for the dbspecific classes. You can do this from the command line, using the CLI generator (Which is in the SDK). You could create a small .cmd/.bat file which generates the code for you properly with the appropriate namespaces. Use 2 folders for the two outputs, and in your solution you reference the generic project from one folder and the dbspecific project from the other.

The option isn't added as the requirement is pretty rare

Thanks for the response.

I was hoping there was another, less cumbersome, alternative but if that's what I've got to do then I can do that.