Value Object Convention

Hi,

I'm using the latest nightly build with VS 2010 / SQL 2008 / .NET 4.0. I have an entity named Hospital with several address fields. I've tried working with the value object convention in the documentation and for the most part things work with the exception of my AddressStateId field, which is a foreign key Id from the State table. The SQL is simple and as follows:

CREATE TABLE [dbo].[State](
    [Id] [int] NOT NULL,
    [Code] [nchar](2) NOT NULL,
    [Description] [nvarchar](50) NOT NULL
) ON [PRIMARY]

CREATE TABLE [dbo].[Hospital](
    [Id] [int] NOT NULL,
    [AddressStreet1] [nvarchar](50) NOT NULL,
    [AddressStreet2] [nvarchar](50) NULL,
    [AddressCity] [nvarchar](50) NOT NULL,
    [AddressStateId] [int] NOT NULL,
    [AddressPostalCode] [nvarchar](50) NOT NULL
) ON [PRIMARY]

ALTER TABLE [dbo].[Hospital]  WITH CHECK ADD  CONSTRAINT [FK_Hospital_State] FOREIGN KEY([AddressStateId])
REFERENCES [dbo].[State] ([Id])
GO

ALTER TABLE [dbo].[Hospital] CHECK CONSTRAINT [FK_Hospital_State]
GO

Through the designer I select the fields I want as part of the value object and it creates it. The designer doesn't show me the AddressStateId field so I'm not able to include it.

I'm aiming for an Address value object with a StateId field.

Any suggestions on whether or not I'm going about this the right way?

Thanks.

This can be a bit fiddly because only entities can have associations: value objects can't.  There are two possible approaches:

1. Define the State association on each entity that uses the Address value type, and on each association add a mapping that tells LightSpeed to use the value object member as the foreign key for that association.  This means the State association may have to be repeated on multiple entities, but allows you to take advantage of all the automatic wiring of LightSpeed associations, and the usage is a bit nicer (e.g. you would write myHospital.State.Code).

2. Add a manually implemented property or method to Address that gets the State entity, and use that when you need state information.  This is a bit neater in the designer, and nicely associates State with Address where it belongs, but requires a bit more manual effort to wire associations, and involves more traversal to reference (e.g. you would write myHospital.Address.State.Code).

Let me know which approach sounds more like what you want and I can provide some more detail on how to go about it.

I've been working with the designer and it seems that option 1 may be suited for a code first development model, maybe? I also wasn't sure how to create a custom mapping as you described.

I'm open to either approach. I'm just looking to take advantage of value objects but haven't tried it with Lightspeed. I plan to update the Lightspeed model from the database as opposed to the other way around for the bulk of the work.

Aargh, I've just been looking further at this and it appears we don't currently support storing foreign keys in value object members.  So that rules out option 1 anyway.  Sorry about that.

For option 2, you need to create a partial class for the Address type.  In the partial class, create a State property as follows:

public State State {
  get { return GetCurrentUnitOfWork().FindById<State>(this.StateId); }
}

The tricky bit here is the GetCurrentUnitOfWork().  If you know you are using scopes (e.g. a Web app using PerThreadUnitOfWorkScope) then this is easy but it ties your model to your deployment model.  So it may be better to put the State property on each of the entities instead:

partial class Hospital {
  public State State {
    get { return this.UnitOfWork.FindById<State>(this.Address.StateId); }
  }
}

The bad news is that because this association is implemented in code, you won't have it appearing on the designer, and Update From Source will want to recreate it.  You can get around this by letting LightSpeed create the association but setting its Generation property to None -- this makes the database sync engine happy that the FK is reflected by an association, but prevents LightSpeed from emitting the unwanted AddressStateId field.

Hope this makes sense -- let me know if you need any more info.