This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi! Is it possible to reference the same Value Object several times in an entity class? Say for instance that you created a Value Object class UrlVO to encapsulate a Url which basically only has one field, namely the URL. But the Value Object is desirable since it allows for business logic associated to the URL to be placed in this UrlVO class instead. Say for instance that you have an entity class that has the following fields and properties: private UrlVO _imageUrl; I reckon this won't work since it is not possible to establish a different naming for the corresponding two fields in the database table. Or? PS. One more thing: I guess the third parameter in this setter above could be omitted in v1.2 since it is the same name? (although I've seen that there is a bug still here). |
|
|
Hi Tobias, Good point. I think a decent solution to this would be to always prefix the value object column names with the respective value object field name from the containing class. i.e. ImageUrl and DestinationUrl result in columns: ImageUrlProtocol The property name inference bug is fixed in nightlies. Cheers, Andrew. |
|
|
I guess you mean prefixing the columns in the database. But I still don't follow you how you make this prefix naming come through in the Domain Model. What change would you do to the Entity Object fields or properties? Could you give an code example to clarify this for me? And how can you possibly achieve this for a Value Object with manye fields and properties?
|
|
|
I've implemented this fix and it will be available in tonights build. To clarify from the help: "Value object column names are prefixed with the name of the value object field on the containing class. For example, let’s say we had a Customer entity with two value object Address attributes: HomeAddress and BillingAddress. Our Customer table would have two sets of columns corresponding to each set of value object fields. The columns would be named like so: HomeAddressStreet, HomeAddressCity etc. and BillingAddressStreet, BillingAddressCity etc." |
|
|
I see. And this will work. Thanks. One question remaining which I will undoubtedly find out when trying. Nevertheless, just to clarify things: should the prefixes on the column name with the entity name always appear when value objects are used, or is it only necessary when the same value object is used twice or more on an entity object? "To clarify from the help:" Where is this stated? I can't find this in the documentation. Some documentation I've missed? Cheers! |
|
|
Hi Tobias, In the Conventions section of the help file. Cheers, Andrew. |
|
|
Ok, I've tried this now and it works fine. Thanks! However I have a suggestion to you. First of all this feature seems to break backward compatibility with LightSpeed 1.1 since it actually requires the tables to be changed to the new convention if Value Objects are being used. For us this is ok since we are not in production yet. But I reckon you have not started to worry about backward compatibility issues yet? However, I have a suggestion that would enable backward compatibility with the 1.1 version as well as giving an additional feature strength: Sometimes it is nice to have a Value Object that Only contains only one field. For instance we have such a ValueObject for URL. It allows us to keep logic associated to a URL in the Value Object instead which is nice. Naturally, this Value Object only has one private field _value with a property Value. However, with the new LightSpeed convention, the database field would have to be labeled SomeURLValue if the referenced property on the entityclass is called SomeURL. A bit awkward I reckon. So, why not having a boolean property on the attribute called multiple? This would enable backward compatibility to 1.1 (if needed) as well as the possibility to have a field in the database that is actually called SomeURL only for multiple=false. (of course single would work also which might be better since one field Value Objects probably is less common) Or perhaps there is an alternate solution to this in place already? Of course we could live with this convention as it is, but I don't particularly like the Value suffix in the database column. For a DBA that is not aware of the Domain Model such a suffix would seem strange I guess. Best regards, Tobias |
|