CODEWITHSUNDEEP
c#asp.netentity-framework
Aleksa
Aleksa

Reputation: 3104

Complex type fields

I want to separate contact information in my User table, and I am thinking of two ways of doing it. First is to make a new table and then my User table references that table through foreign key.

Or to make complex type which is part of the User table, by adding [ComplexType] annotation to Address field.

This is Address class, just an example:

public class Address
{
  public string City {get; set;}
  public string Street { get; set; }
  public string Country { get; set; }
  public string Phone { get; set; }
}

What do you recommend me to do? Which is better way?

Upvotes: 1

Views: 954

Answers (3)

Bassam Alugili
Bassam Alugili

Reputation: 16993

If you ask this quesition for a clean coder then just he will answer you with two entities/classes SRP http://www.oodesign.com/single-responsibility-principle.html

If you ask the same quesition for a database delevoper then his answer will be no joins use complex types.

Me as a developer I find Complex Types has some limitation and I will never use them.

Here I will copy from http://weblogs.asp.net/manavi/associations-in-ef-4-1-code-first-part-2-complex-types the pros and cons of the complex types:

There are three important limitations to classes mapped as Complex Types:

  • Shared References is Not Possible: The Address Complex Type doesn’t have its own database identity (primary key) and so can’t be referred to by any object other than the containing instance of User (e.g. a Shipping class that also needs to reference the same User Address, cannot do so).

  • No Elegant Way to Represent a Null Reference: As we saw there is no elegant way to represent a null reference to an Address. When reading from database, EF Code First always initialize Address object even if values in all mapped columns of the complex type are null.

  • Lazy Loading of Complex Types is Not Possible: Note that EF always initializes the property values of a complex type right away, when the entity instance that holds the complex object is loaded. EF does not support lazy loading for complex types (same limitation also exists if you want to have lazy loading for scalar properties of an entity). This is inconvenient when we have to deal with potentially large values (for example, a property of type byte[] on the Address complex type which has been mapped to a VARBINARY column on Users table and holds an image of the location described by the Address.).

Best Practices you can read it in the given link above.

Upvotes: 1

Nazir Ullah
Nazir Ullah

Reputation: 610

Your First (Separate table) choice is better, because single user have multiple contact records then it is better to handle this in separate table by foreign reference.

it is also better for changes in its contact info , means permanent address , postal address , resident contact no , self contact no and so on ,you can easily updated this in separate table ,

and this is the good practice of normalization in database

Upvotes: 1

Fourat
Fourat

Reputation: 2447

Well there's no perfect choice for this, it depends on the multiplicity: if a user have multiple addresses then you need to go with the foreign key option, if a user has only one address the you can either add the address fields to the user fields (simple) or use [ComplexType]

Upvotes: 1

Related Questions