Help with asymmetrical ValueObjects

 Hi, I have the following scenario:

A User class that has two entries of a ValueObject called "PersonalInformation"

 The User class has two properties, "ParentPersonalInformation" and "UserPersonalInformation".

 The PersonalInformation class has a bunch of properties.

The problem is, one of the properties, "DateOfBirth", does not exist for the parent, only the user.

 i.e. there is a "user_date_of_birth" field in the database but no "parent_date_of_birth".

Is it possible to tweak LightSpeed to allow for these asymmetrical ValueObject properties, where a property may or may not exist for all instances of the ValueObject?  Thank you

Would it not make more sense to define two classes, PersonalInfo and PersonalInfoWithDOB, with PersonalInfoWithDOB inheriting from PersonalInfo (and adding the DateOfBirth property)?

The caveats with this being:

1. You'd have to make them classes rather than structs (because of the inheritance).  That shouldn't be a problem, just a stylistic thing.

2. You'd have to do this in handwritten code rather than the designer (because the designer always generates structs, has no way of modelling inheritance amongst value objects, etc.).

If this approach makes sense, but you'd like to use the designer for it, let us know and we'll see what we can do.  I think we'd rather tackle it by helping you create a good OO model than by kludging an invalid field away at the database level.  But we're open to feedback if you've got a strong reason for using the same VO type for both (e.g. the parent does have a DOB, it's just not persisted): I am thinking about "asymmetric" customisation of VO storage, specifically for column mapping in legacy scenarios, but I'm sure I could apply it to transience as well.

 I find it easier to limit the number of classes I have to declare, especially if it only differs by (in our case) 1 field.

 And conceptually, a parent does have a date of birth, its just that we don't care about it and aren't recording it in the database :)

 I don't mind creating mappings in code at all, but I would much rather stick to using the one PersonalInfo object.

I would actually love to see your team implement a fluent mappings type functionality, to allow for cases like this (similar to a Fluent NHibernate, where its all lambda expression-based).

Okay, I'll log a feature request for this.  Unfortunately, I'm not sure when we'll have time to tackle this, so for the time being you'll have to use the two-class approach.  Sorry.

Could you say why you'd like to see a fluent mapping approach?  We have preferred an attribute-based style of mapping (e.g. TableAttribute, ColumnAttribute): what do you see as the benefits to you of a fluent representation of the mappings?

The main benefit of having a fluent-based approach, is that you can look at the mappings for all your columns and tables very quickly, and scan it visually to check for errors, etc.  When using the visual designer, I have to click on each property one by one to see if it is potentially missing its column mapping, or to see if it is not mapped correctly, etc.

For me personally, I just like looking at a class such as:

    public class UserMap : ClassMap<User>
    {
        public UserMap()
        {
            DynamicUpdate();
            Schema("TDL_Game");
            Table("user");
            Id(x => x.Id, "user_id").GeneratedBy.Identity();

            Map(x => x.UserName, "user_username");
            Map(x => x.Password, "user_password");
            Map(x => x.Status, "user_status");
            Map(x => x.ChatType, "user_chat_type");
            Map(x => x.FreeOrPaid, "user_free_or_paid");

            Map(x => x.UserLastLogin, "user_last_login").Nullable();
            Map(x => x.UserLastGameLogin, "user_last_game_login").Nullable();
            Map(x => x.UserRegistered, "user_registered").Nullable();
            Map(x => x.ParentLastLogin, "parent_last_login").Nullable();

            Component(o => o.UserPersonalInfo, m =>
                {
                    m.Map(x => x.Email, "user_email");
                    m.Map(x => x.Gender, "user_gender");
                    m.Map(x => x.DateOfBirth, "user_date_of_birth");
                    m.Map(x => x.FirstName, "user_first_name");
                    m.Map(x => x.LastName, "user_last_name");
                    m.Map(x => x.StreetAddress, "user_street_address");
                    m.Map(x => x.City, "user_city");
                    m.Map(x => x.State, "user_state");
                    m.Map(x => x.Zip, "user_post_code");
                    m.Map(x => x.Country, "user_country_code");
                    m.Map(x => x.PrimaryPhone, "user_primary_phone");
                    m.Map(x => x.SecondaryPhone, "user_secondary_phone");
                });

            Component(o => o.ParentPersonalInfo, m =>
            {
                m.Map(x => x.Email, "parent_email");
                m.Map(x => x.FirstName, "parent_first_name");
                m.Map(x => x.LastName, "parent_last_name");
                m.Map(x => x.StreetAddress, "parent_street_address");
                m.Map(x => x.City, "parent_city");
                m.Map(x => x.State, "parent_state");
                m.Map(x => x.Zip, "parent_post_code");
                m.Map(x => x.Country, "parent_country_code");
                m.Map(x => x.PrimaryPhone, "parent_primary_phone");
            });

            HasOne(x => x.GameSettings).PropertyRef(p => p.User).Cascade.All();

            HasMany(x => x.Comments).Table("user_comments")
                .KeyColumn("user_id")
                .Cascade.All();

            HasMany(x => x.Buddies).Table("users_buddylist")
                .KeyColumn("user_id")
                .Cascade.All();

            HasMany(x => x.IgnoredUsers).Table("users_ignorelist")
                .KeyColumn("user_id")
                .Cascade.All();

            HasMany(x => x.Avatars).Table("avatar")
                .KeyColumn("user_id")
                .Cascade.All();
        }
    } 

I love lambda expressions, and to me that is just easy to read and verify.  Maybe I'm in the minority on this, but I would love to see such a thing supported in a future version of LightSpeed.

If you look at the mapping example above, the "Component" function is the equivalent of a LightSpeed ValueObject, and if you see how it is mapped above, you can see that the mappings are asymmetrical.  Not only that, but due to the fact that you are specifying the mapping explicitly, you don't have to worry about the "parent" or "user" prefix being slightly different from column to column.  If there is a difference (maybe the DBA mispelled it, and it is too late to fix it for the current software release), then you can specify that difference via the mappings.

Marc, thanks for the great and detailed feedback.  We don't have any plans for this at the moment, but knowing the reasons why people like this approach definitely helps us to understand when and how to invest in it.  And as you note it does help to solve the asymmetric mapping issues we currently have with value objects.  We'll definitely keep this in mind as a possible future feature.

One thing that might help in terms of setup, reading and verifying would be a "mappings view" in the designer, where you could see the entities and properties in a tree view with their mappings.  That would support rapid scanning and editing of the mappings.  Unfortunately, this is a long-standing wish that we haven't yet been able to find time for either...