I'm trying Domain components for the first time and set up a simple object as follows
public interface iAccount
{
[RuleUniqueValue("Account ID must be unique", DefaultContexts.Save)]
int ID { get; set; }
}
Added the validation module to the base module for my app (project atrtached) and when I try to save a record I get the following error.
An exception occurs while validating an object:
Exception: 'The 'This' property path is incorrect for the 'khacc.Module.iAccount' type because the 'khacc.Module.iAccount.This' member does not exist'
Rule Id: 'Account ID must be unique'
Rule Type: 'DevExpress.Persistent.Validation.RuleUniqueValue'
Target Object: 'Power'
Ticket
Q292088
Visible to All Users
Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Hello Richard,
Thank you for your message. I am afraid this functionality is not currently supported by the Domain Components technology. However, it is possible that this scenario will be supported once DC is released.
I have created a corresponding bug report internally.
Thanks,
Dennis
P.S.
It is also 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). See also: 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.
Should it not be defined as follows: iCategory CategoryID { get; set; }, assuming that iCategory is a corresponding domain component? Otherwise, you will loose the default lookup and other standard functionality for the integer CategoryID field.
The situation is much better in 10.2, but DC will be still in Beta. Good news, we will provide a DC demo application to help our users get started with DC easier: Demos - Provide a demo based on the Domain Components (DC) technology.
Hi Dennis,
Thanks for the reply, and for creating the bug report.
I'm building a General Ledger. The Account.Name and Account.ID must be unique even if they are "user friendly". They are not the primary key which is still the autogenerated oID, although I personally believe they should be.
I've had this argument with Roman before about primary keys. I believe the database should enforce system integrity, I've always designed Databases that way using features like compound primary keys to define unique identifying attributes of a table row, or triggers. As I understand it, Roman's position was that the application should enforce these things transparently from the user (and developer), and that the developer shouldn't have to worry about things like primary keys. I understand his point of view, but in an environment like this where you have external applications, query tools and analysts that have to also access the same data I believe it is a system weakness if the database doesn't enforce rules like Account.ID must be unique. Ideally I would have the ID as the primary key, and Name would be ensured unique using a trigger, that way the database ensures correctness from all access and teh side benefit is that someone querying a referential table like say a transaction table sees the refferential link as a "user friendly" value without having to join to the Account table just for find out what Account ID a transaction is for, rather than some autogenerated number or GUID.
I did make Category a lookup into another BO, I was just trying to simplify the case I presented to you to one BO.
I like your idea of an AfterChange method, however it wouldn't be usefull in this case where only some of the fields I care about (eg: I don't care if the UpdateDate or Updater field is changed :)
Hello Richard,
We appreciate your feedback.
I also share Roman's position, but as I already mentioned above, it is still possible to force the ID property to be a PK. In order to do this, you should create your own base class and then use it during the registration of your entity. As for a unique Name, I have created a suggestion to provide one more DC attribute, allowing to specify that an index will be created for the respective column in the database.
Meantime, you can add this index manually in your database table.
Thanks,
Dennis
Thanks for your response.
I probably will use custom classes rather than interfaces because that should allow me to have a clear, elegant, self documenting database structure. This is a good feature for a general ledger (or any enterprise application) which one can expect to have multple third party accessors that are not XAF based applications.
See Also:
Key Attribute DomainComponent
Thanks,
Dennis