Key Attribute DomainComponent

Hi Max,
Thanks for the feedback.
Currently, it's not possible to mark a particular DC interface property so that it would be used a key property. You can only select a base class that will be used when generating an entity for your interface (http://documentation.devexpress.com/#Xaf/CustomDocument3262).
I have created a suggestion in this regard: DC - Make it possible to mark an interface property so that it could be used as a key when generating a class for that interface.
Thanks,
Dennis

Hi Max,
Do you need the capability to set a key property for the auto generated class because you want to map your DC interfaces to an existing database?
If not, then I would love to learn more about your intentions. Thanks for the feedback in advance.
Thanks,
Dennis

Hi Dennis,
as well as for new and existing, you always will have tables where does it makes no sense to have int/guid as PK. i.e. for Country table you can have ISO 3166-1 alpha-3 as PK its just 3 bytes and human readable, another example is may be Tax table where you will have max. 10 types of tax records so that 2-3 bytes human readable key is more suitable than 36bytes GUID or int…another example is Unit class (ps, kg, mm, km, m3 ) no need to use a sledgehammer to crack a nut.
Best regards
Max

Hi Max,
Thanks for the clarification. Your scenarios, of course, make sense. To implement them in DC, you will have to provide your own base class with required keys when registering an entity for an interface.
For example, you can create a CountryBase class with a CountryId key property and then use it in the XafTypesInfo.Instance.AddEntityToGenerate method when registering your ICountry interface.
However, let me first elaborate more on how I would solve your particular problem and also on the primary DC purpose.
In my opinion, you should never make ISO 3166-1 alpha-3 or 2-3 bytes human readable keys as PK. These are more friendly keys and not primary keys. Usually, a primary key should not hold any logic. It should just be a unique identifier of a record in the database table and nothing else. That's why a GUID or auto-incremented integer is always good as PK.
Now regarding DC, I should say that it's not a replacement of persistent objects at all. This technology is good for certain scenarios only. The main DC benefits are described in the http://documentation.devexpress.com/#Xaf/CustomDocument3262 help topic and related videos on our TV-channel. For example, DC is very good when you want to create reusable domain components from several interfaces and domain logics.
Suppose you have created a library with two interfaces - ICountry and IState. You then sell your library to your client, and he or she wants to create a custom component based on your interfaces:
public interface ICustomComponent: IState, ICountry, ISomethingElse{ …}
What to do if each of these interfaces has its own key? This example demonstrates that usually you should not define a key in your DC interface. In most cases, an auto-generated key is already OK.
If you don't think that you will benefit from using DC, then it's better to continue using persistent classes for your tasks.
Let me know if you need any further clarification on the subject.
Thanks,
Dennis