Using LLBLGen pro trial(just downloaded newest version today).

Generating code for EF 6 and .NET 4.6

Is there a configuration for adding a suffix to entity names, or do I need to modify templates?

I want entities named TenantEntity instead of Tenant. I will have model classes that will have similar names and I have always liked that llblgen Entities have that suffix so it is clear to newer developers what are simple pocos and what are database entities.

For existing projects that we use LLBLGen as the data provider, having the *Entity suffix has been a useful distinction and improves readability and ease of reviewing code for mistakes. I.e. it's clear if someone modifies a property of a TenantEntity but doesn't save that change it's easy to distinguish from code that is just modifying a simple poco.

I know EF code first entities are pocos, but they still represent entities who's state should be saved, as opposed to other poco's that are just projections for passing around through the application. I'd really like to continue this pattern of the *Entity suffix.

What's the best approach to getting the EF v6 CodeFirst generation to add a *Entity suffix to generated entities?

Also I'd suggest adding Model and Persistence folder name options to the EF project settings, similar to LLBLGen's Project level settings, otherwise you have to edit a half dozen locations in the code generation Preset to move the output from Model to Entities subfolder. Maybe there's an easier way.

I wouldn't recommend to change the template here, as other templates rely on the entity name, so it could crash in your generated code. You still could change the entity names in your model. To do it in batch you could write your own plugin, or use the 'Search' tool to run the modification for all entities.

However, as it's a standard for EF to treat entity names like that (without the 'Entity' suffix), I would recommend to leave it as-is.

About your feedback, I understand why you want this, though the only feedback we actually received over the years is whether we could get rid of the 'Entity' suffix of our own entities, so it's a breath of fresh air to read you actually want to keep it

We didn't add the feature for the suffix because of the previous feedback we received about our own framework.

Yeh, I saw those threads when searching around

Is there any support for integrating DB Schema names into the C# namespace hierarchy of the generated entity classes? Or are DB Schema names basically not represented in generated code?

Why do you want schema names in namespaces? IMHO, it shouldn't be represented in code.

If you must, you can, but it's only supported when using grouping mechanism in the designer and then set to As Separate Projects. You can then define the entities per group, and auto-set the group name after the schema when reverse engineering.

Then it will automatically generate the code per group into separate projects with the groupname as a suffix to the namespace, however this has limitations of course, as it doesn't allow relationships to cross groups, and it generates per group a separate vs.net project.

The Additional Namespace feature of the taskgroup doesn't have macro resolving so it's not currently supported to resolve the additional namespace defined in a preset from a macro which e.g. contains the group name.

Walaa wrote:

Why do you want schema names in namespaces? IMHO, it shouldn't be represented in code.

In SQL Server schemas are often used to provide specificity or segment large DB models. Which are exactly the two properties that namespaces provide in C#. If you're using schemas to segment ownership like "dbo", then I'd agree you wouldn't want that in C#, but these days you usually use roles to manage ownership and use schemas to group tables into namespaces like "HumanResources.", "Product.", etc.

Problem arises when you have the model mapped to sql server and e.g postgresql. You'll then get 1 entity model project and 2 projects with a context / mapping information. the entity namespaces then don't reflect the DB, as they're mapped to two databases.