Hai,

How can I remove the <Entity> suffix for all the entity classes that are generated through the Single Scenario.

Regards, Ravi

That's by design and can't be removed. It's not recommended to alter the templates in such a way that 'Entity' is stripped from all names (you can, in theory, do that), as the Entity suffix ensures that name clashes with other names are rare

I made the mistake of doing this early on in our project, by altering the template files. Major mistake, as updates/bug fixes to the template files now need to be done manually. I would suggest not doing this.

However, it would have been nice to have this be some kind of setting we could configure, in case we wanted to drop the 'Entity' or replace it with something else.

Why did you want to remove the suffix, if I may ask?

Otis wrote:

Why did you want to remove the suffix, if I may ask?

In my case, it was just how "things were done" here. It was desired to be able to type

Dim thisEmployee as new Employee

instead of

Dim thisEmployee as new EmployeeEntity

It is a bit more readable this way, but like you said, causes naming conflicts.

Otis wrote:

That's by design and can't be removed. It's not recommended to alter the templates in such a way that 'Entity' is stripped from all names (you can, in theory, do that), as the Entity suffix ensures that name clashes with other names are rare

Where do the name clashes occur? Within generated code or externally?

I, like mikeg22, changing the templates once but its too much trouble to keep in sync with the release templates.

If the perceived problem is only with external code then I too would love an option to remove/replace the suffix.

Cheers Simon

Within generated code, the risk is there that classes in the .NET framework for example clash with the entity names.

Otis wrote:

Within generated code, the risk is there that classes in the .NET framework for example clash with the entity names.

I see but I think it unlikely and easily fixable (rename the entity to something else)

+1 for an entity name suffix option.

Cheers Simon

simmotech wrote:

Otis wrote:

Within generated code, the risk is there that classes in the .NET framework for example clash with the entity names.

I see but I think it unlikely and easily fixable (rename the entity to something else)

Sure, it's easily fixable, though the reports we've had in the past years about people having properties named like 'Transaction' or something and then get weird compile errors (as the compile errors resulting from these name clashes are often cryptic and occuring in areas you don't expect them), suggest that it's not that unlikely .

+1 for an entity name suffix option. Cheers Simon

Added to todo list though I'm not sure if it will ever make it into the code.

One other thing to add, is that in general, naming classes should be done like (and I'm rehashing Brad Abrams' advice here from Framework design guidelines) [i]YourType[i]BaseType.

So if you have a class which derives from Collection and thus is a collection but contains Customers, the name to pick is CustomerCollection, not Customers.

A class which derives from Entity and is thus an entity, should be called e.g. CustomerEntity, not Customer.

But I've to admit, that was rationalization after the deed: I already picked the names way before I read Framework design guidelines

Your name-clash argument is definitely better than this particular argument (otherwise every object should have an "Object" suffix; "xxxTypedList" would become "xxxTypedListDataTable" or even "xxxTypedListDataTableObject")

To me, "object", "entity", "item", "thing" are all just attributes of no particular meaning.

"Person", "Invoice", "Customer", "Employee" are articles (had to use a thesaurus to find another synonym of "object" ) with a specific meaning - their underlying inheritance structure is really just an implementation detail.

Using just the simple, everyday name in code will always be more readable in my eyes. T'would be nice to have the option and leave its default to "Entity".

Actually, I love some of the naming conventions in LLBLGenPro: Predicate and PredicateExpression - maybe its because I don't have an academic computer science background but I have to stop everytime I see these and mentally translate to "filter" for my simple brain. But then at the other end of the scale there is a "RelationPredicateBucket" - I love having "Bucket" in my code!

I'm just grateful you didn't go the whole hog and refer to "tuples" and "attributes" instead of "rows" and "columns"

Cheers Simon

Yeah, the guideline of putting the parent class name in the suffix is generally a good guideline to avoid confusion (and naming conflicts) but I think is a waste when it is pretty obvious what the class is all about. For example, I would never get confused in our application seeing the line:

Dim x as new Customer

and knowing that 'x' represented a customer. However, this is because we use our entities as actual domain objects so that they contain pretty much all their pertinent business logic. Using the entities for just data transport, however, should give them a suffix of DTO or something like that. In this case, the 'Entity' suffix is less descriptive than a 'DTO' suffix.

So, I'd vote for suffix configurability

simmotech wrote:

Your name-clash argument is definitely better than this particular argument (otherwise every object should have an "Object" suffix; "xxxTypedList" would become "xxxTypedListDataTable" or even "xxxTypedListDataTableObject")

Yeah, I agree, though it's the reasoning why classes which are Exceptions and thus derive from exception, should have an Exception suffix. It's not consistent, I fully agree. (there are more silly things in these guidelines though. No 'Enum' suffix, though attributes have to have an Attribute suffix)

To me, "object", "entity", "item", "thing" are all just attributes of no particular meaning.

"Person", "Invoice", "Customer", "Employee" are articles (had to use a thesaurus to find another synonym of "object" ) with a specific meaning - their underlying inheritance structure is really just an implementation detail.

Using just the simple, everyday name in code will always be more readable in my eyes. T'would be nice to have the option and leave its default to "Entity".

I'll see what I can do, it's not that simple though as it's a lot of work.

Actually, I love some of the naming conventions in LLBLGenPro: Predicate and PredicateExpression - maybe its because I don't have an academic computer science background but I have to stop everytime I see these and mentally translate to "filter" for my simple brain. But then at the other end of the scale there is a "RelationPredicateBucket" - I love having "Bucket" in my code!

I'm just grateful you didn't go the whole hog and refer to "tuples" and "attributes" instead of "rows" and "columns" Cheers Simon

Every time I read 'Tuple' I have to look it up myself, as I always associate 'tuple' with a pair.

'Predicate' is a term I looked up as well, as I needed a term for a where clause element, and it happened to be 'Predicate', so I kept that. I didn't use attribute because it would normally clash with the concept of '.net attribute' so I opted for 'field'

mikeg22 wrote:

Yeah, the guideline of putting the parent class name in the suffix is generally a good guideline to avoid confusion (and naming conflicts) but I think is a waste when it is pretty obvious what the class is all about. For example, I would never get confused in our application seeing the line:

Dim x as new Customer

and knowing that 'x' represented a customer. However, this is because we use our entities as actual domain objects so that they contain pretty much all their pertinent business logic. Using the entities for just data transport, however, should give them a suffix of DTO or something like that. In this case, the 'Entity' suffix is less descriptive than a 'DTO' suffix.

So, I'd vote for suffix configurability

Though isn't that a little limiting? I mean: if you intent to use them as DTO's, and at one point in time you have to use them as more than dto's, you're running into a problem, where you've named your class as if it does A, but it's doing A'

Otis wrote:

Though isn't that a little limiting? I mean: if you intent to use them as DTO's, and at one point in time you have to use them as more than dto's, you're running into a problem, where you've named your class as if it does A, but it's doing A'

Yeah, but I don't think I would ever use it as more than a DTO. If I wanted to do more with it, I would probably use encapsulation to give it more ability.