Julie's on Twitter @julielerman... Best way to get a conversation going...

+++ Rick ---


>Hi,
>
>I am reading this http://msdn.microsoft.com/en-us/data/gg193958:
>
>However as a property in the Blog class, BlogDetails it will be tracked as part of a Blog object. In order for code first to recognize this, you must mark the BlogDetails class as a ComplexType.
>

>[ComplexType]
>    public class BlogDetails
>    {
>        public DateTime? DateCreated { get; set; }
>        [MaxLength(250)]
>        public string Description { get; set; }
>    }

>Now you can add a property in the Blog class to represent the BlogDetails for that blog.
>
> public BlogDetails BlogDetail { get; set; }
>In the database, the Blog table will contain all of the properties of the blog include the properties contained in its BlogDetail property. By default, each one is preceded with the name of the complex type, BlogDetail, as you can see in Figure 3.
>
>
>Figure 3: The Blogs database table containing columns that map to a complex type
>
>Another interesting note is that although the DateCreated property was defined as a non-nullable DateTime in the class, the relevant database field is nullable. You must use the Required annotation if you wish to affect the database schema.
>
>---------------
>The note seems a bit contradicting to me. We did define the date as nullabale type in the ComplexType, right?
>
>I also want to ask Julie what does she think of my particular case where I have EnteredBy/EnteredOn and ModifiedBy/ModifiedOn - should it be a complex type and two properties of this type (but EnteredOn and ModifiedOn are linked to Operators table) or should I code them both as simple properties in the class instead?