a.m. wrote:Hi,
Thanks for suggestion. I agree that it could convenient for some vendors. But having this property just for such cases (when you have entities with names such as already "reserved" system entities) is a bit redundant. This property will make source less readable.
So you'll have to use some other class name (not "Category"). Furthermore, it's a bad practice to have two entities with the same name in distinct namespaces.
Hi Andrei,
Of course we can rename it and we would have just done it without even bothering to write to you about it.
So my point was not to change this for the sake of changing it but to let the developers some freedom.
Why the core entity name should be "reserved"?
Now we have unnecessary restrictions to how to name our entities, which I can't call a good practice.
I think the plugin developers should be able to call their classes whatever they want to (actually if they have to follow the best practices they should name their entities with meaningful names and not
SS_Category), without being restricted and without worrying that some other vendors might have decided to give their entity the same name and could break their plugins.
In the SaveSlug<T>(T entity, ...) where T : BaseEntity,
ISlugSupported method the logic is like this:
string entityName = typeof(T).Name;
...
var urlRecord = new UrlRecord()
{
...
EntityName = entityName,
...
};
For me this is an unnecessary restriction to name my types the same way I want them persisted in the database.
This is also not a good practice. This coupling of the names of the classes with how they are persisted to the database is a bad thing.
It would be better to have something like this:
string entityName = entity.EntityName;
And let each entity that is
ISlugSupported to specify how it should be persisted in the
UrlRecord table.
I don't think the code will get more complex as currently we have an empty
ISlugSupported interface used only as a generic constraint but it is not used for anything else. Some people might say that the current code implementation is more complex as it requires an interface that is used nowehere.
I agree that in some cases it is not good to have several classes with the same name in different namespaces but this is only if you plan to use them both somewhere in your code. Actually .NET Framework is full with classes with the same names but in different namespaces. So I would say it is a matter of personal preferences. For example we don't plan to use our category entity together with the nop category in the plugin's code, so it is absolutely ok to name it just "
Category".
Anyway I felt I was obliged to suggest it.
Thanks