I really dislike having 'Entity' at the end of every entity class name (for the same reason I don't add 'Object' at the end of every other class name)

It would be nice to have a project option for an EntityNameSuffix (set to "Entity" by default) so that I can get 'Person' and 'PersonBase' rather than 'PersonEntity' and 'PersonEntityBase'.

(I thought I had seen an option for this but I think I must have been confused with the filenameFormat which actually does allow this and the docs which mention "The base class, generally named EntityNameEntityBase.cs/vb, for example" - note the 'generally')

If this can't be added as an option, I could modify the standard templates to achieve this but are there any hidden assumptions about an entity's name??

Cheers Simon

no, other than that you run the risk of having duplicate names. The reason 'Entity' is added is partly because it's in the MS framework guidelines (CustomerEntity is an Entity subtype, thus Entity should be its suffix) and partly because it solves the problem of name clashes with .NET framework names and/or other elements in the generated code / runtimes.

Otis wrote:

no, other than that you run the risk of having duplicate names. The reason 'Entity' is added is partly because it's in the MS framework guidelines (CustomerEntity is an Entity subtype, thus Entity should be its suffix) and partly because it solves the problem of name clashes with .NET framework names and/or other elements in the generated code / runtimes.

I've not seen that anywhere in the MS framework guidelines. If I have an inheritance chain of Party->Company->Customer then wouldn't it be 'CustomerCompanyPartyEntity' - doesn't make sense to me. Again, class names don't have an Object suffix and, in the designer, entities don't display a suffix.

I see the point about name clashes but I don't see it as a big risk.

No chance of an option then? :-)

Actually I think I will end up using a copy of the standard templates anyway. I have two additional requirements for all my entities: 1) IFormattable 2) A 'This' property which is helpful in databound grids to allow IFormattable to be used on ToString() (as used and recommended by DevExpress)

If I am modifying standard templates anyway then I can put in an intermediate class before EntityBase2 and there is then just one place to add inherited code for all generated entities without code duplication/recompiling of support classes (Please tell me if I am way off base here)

Cheers Simon

simmotech wrote:

Otis wrote:

no, other than that you run the risk of having duplicate names. The reason 'Entity' is added is partly because it's in the MS framework guidelines (CustomerEntity is an Entity subtype, thus Entity should be its suffix) and partly because it solves the problem of name clashes with .NET framework names and/or other elements in the generated code / runtimes.

I've not seen that anywhere in the MS framework guidelines. If I have an inheritance chain of Party->Company->Customer then wouldn't it be 'CustomerCompanyPartyEntity' - doesn't make sense to me. Again, class names don't have an Object suffix and, in the designer, entities don't display a suffix.

Read the book "Framework design guidelines" by Brad Abrams. It's in there. It's suggested to have a suffix which describes the supertype, if possible. Like: a custom treeview with multiselect, you should call it MultiSelectTreeView.

I see the point about name clashes but I don't see it as a big risk.

I do see it as a big risk, as I never ever want to have a customer having incompilable generated code.

No chance of an option then? :-)

I fear that's not going to be added . I understand you don't like the suffix, but IMHO not something worth to invest a lot of time in, as changing it won't add anything to the functionality.

Actually I think I will end up using a copy of the standard templates anyway. I have two additional requirements for all my entities: 1) IFormattable 2) A 'This' property which is helpful in databound grids to allow IFormattable to be used on ToString() (as used and recommended by DevExpress)

You can add IFormattable automatically to the generated code by adding that interface to the entities in the code gen. properties tab. Either manual or through the supplied plugin . A 'This' property? Never saw that pattern before.

If I am modifying standard templates anyway then I can put in an intermediate class before EntityBase2 and there is then just one place to add inherited code for all generated entities without code duplication/recompiling of support classes (Please tell me if I am way off base here)

That's indeed correct. You can add such templates much easier now. Just create your own templatebindings file with just that custom entityAdapter.template binding and place it in the templates folder. In the code generation configuration window, go to the second tab and place your custom templatebindings file with just your own template above the general templates shipped by us and you overrule the default template binding with your own. No more messing with standard config files

Otis wrote:

Read the book "Framework design guidelines" by Brad Abrams. It's in there. It's suggested to have a suffix which describes the supertype, if possible. Like: a custom treeview with multiselect, you should call it MultiSelectTreeView.

I see the point about name clashes but I don't see it as a big risk.

I do see it as a big risk, as I never ever want to have a customer having incompilable generated code.

OK, fair enough - thats a better argument than the one above (I have Brad Abrams book and very good is it too - however, there are very few framework classes derived from Control that actually use 'Control' as a suffix )

You can add IFormattable automatically to the generated code by adding that interface to the entities in the code gen. properties tab. Either manual or through the supplied plugin . A 'This' property? Never saw that pattern before.

In my understanding of complex binding, binding to a property that returns a non-value type such as another entity has limited usefulness since it is not possible to use a '.' in the DataMember to return a property of the child entity as you would be able to with simple binding. However, you do get the .ToString() result (or IFormattable.ToString() if supported). So by changing the ToString for my AddressEntity to return useful information such as a concatenated address summary, I can place it on a grid or report column. By implementing IFormattable, I can implement format specifiers and let the Grid choose between a full address ("f")or just City, Country ("c") for example. It isn't directly possible to get to the ToString() result for the parent entity however. Using an empty DataMember doesn't work though you might think it would. But having "object This { get { return this; } }" for all entities would achieve the same result. Just set the DataMember to "This" and specify any available custom format specifiers.

If I am modifying standard templates anyway then I can put in an intermediate class before EntityBase2 and there is then just one place to add inherited code for all generated entities without code duplication/recompiling of support classes (Please tell me if I am way off base here)

That's indeed correct. You can add such templates much easier now. Just create your own templatebindings file with just that custom entityAdapter.template binding and place it in the templates folder. In the code generation configuration window, go to the second tab and place your custom templatebindings file with just your own template above the general templates shipped by us and you overrule the default template binding with your own. No more messing with standard config files

This sounds good!

Cheers Simon