Develop Reference

Entity Framework 5 and TPT design issue

I am doing code first and using a Table-per-type design. I am getting the following error when I extend the second object to multiple tables:
A value shared across entities or associations is generated in more than one location. Check that mapping does not split an EntityKey to multiple store-generated columns.
My database looks like:
Thanks for the up-vote, editing to add my picture:
The POCO for the project looks like:
public abstract class Project {
public int ProjectID { get; set; }
public string Title { get; set; }
public string Description { get; set; }
public virtual ICollection<Tag> Tags { get; set; }
public virtual ICollection<LocationElement> LocationElements { get; set; }
public abstract string getProjectIdentifier();
}
And for a Location Element:
public enum HowObtainedCodes {
Provided = 1,
Estimated = 2,
Summarized = 3
}
public abstract class LocationElement {
public int LocationElementID { get; set; }
public int ProjectID { get; set; }
public HowObtainedCodes HowObtainedCodeID { get; set; }
}
And for a point:
[Table("ProvidedPoints")]
public class ProvidedPoint : LocationElement {
public double Lat { get; set; }
public double Long { get; set; }
public string Description { get; set; }
}
The link from projects (abstract) to scientific licences works fine, and my objects load / persist as expected. Further I can add LocationElements object in if I make it not abstract. As soon as I extend LocationElements and try to save a ProvidedPoint object I get the above message. My first thought was that the LocationElementID on ProvidedPoints was set as an Identity column, but this was not the case.
My question is: Am I doing something unexpected by trying to link two TPT objects together in this way? Am I missing something else?

As noted by #leppie above, I had to decorate the LocationElement class with the annotation [Table("LocationElements")], which immediately fixed the problem. My understanding with EF was that this was not necessary with the base table for a TPT design, and further I had not done it on the Project / ScientificLicence pair (that is, I only decorated the ScientificLicence object).
I am assuming this has something to do with the way LocationElements are added/persisted when I save a new Project object. If anyone has any additional insight I would love to know more.
Hope this helps someone else and a big thank you to leppie!

Model and partial model, how to avoid the redundant code?

I have a model and a partial model which contains only the properties that I need to expose in JSON.
But the properties between the model and his partial model are redundant.
How can I avoid that or improve my approach?
namespace Dashboard.Models.UserModels
{
public class UserModel
{
public int id { get; set; }
public string dbName { get; set; }
public string firstname { get; set; }
public string lastname { get; set; }
public int idExternal { get; set; }
public int idInstance { get; set; }
public string login { get; set; }
public string password { get; set; }
public DateTime? dtContractStart { get; set; }
public DateTime? dtContractEnd { get; set; }
public string emailPro { get; set; }
public string emailPerso { get; set; }
public LuccaUserModel()
{
idInstance = -1;
}
// partial model for json result
// not sure is the best way or have to be here
public class PartialUserModel
{
public int id { get; set; }
public string firstname { get; set; }
public string lastname { get; set; }
public string emailPro { get; set; }
public string emailPerso { get; set; }
public DateTime? dtContractStart { get; set; }
public DateTime? dtContractEnd { get; set; }
public string url { get; set; }
}
// UserModel Methods
}
}

You can rename PartialUserModel UserModelBase class (or leave it as is... it just makes better logical sense to do so) and make UserModel to inherit from it:
public class UserModel : UserModelBase
{
...
}
Of course you'll need to remove all duplicate properties from UserModel in this case.

It's a thin line between doing a proper design and building an overkill design. Answer depends on many inputs, among which I chose to have project and model breadth most important.
In hope to have my answer clearer, I have to say I use different terminology. Data which is adopted for use in UI is usually called ViewModel. In your case, you would build UserViewModel which contains necessary subset of information.
If I'm working on a one-off project, I'll reuse model as a ViewModel. I'll do this by having helper method which removes sensitive information, loads up or cuts off data which is lazy loaded from database and does other preparation on data. All this is done with same model class.
If it's not a short term project, I look to create separate ViewModel classes which I map from model data. Then, if I'm working with mostly flat data I use AutoMapper tool to have data automatically copied, instead of writing my own mappers.
As another answer here states, you write a basic class with data you need in UI and extend it with other model data, however this is not a good approach for several reasons.
If violates separation of concerns. Project dealing with model and persistance should not know about your ViewModel
You may need to flatten data from related objects into ViewModel objects. In that case, your model objects would have fields which should not be there, or would be redundant.
You may need calculated fields and helper methods in ViewModel which would again end up in model, confusing everyone that is not updated about design.
You could want to adopt several unrelated model classes to same ViewModel class
To try and put it shortly, either reuse model class or create ViewModels. There is unfortunately no clever solution. If you find one, please post a comment as I'd like to hear about it :)

Entity Framework Code First, DTO and n-tier scenario (WCF)

I've read several articles about bunch of EF and DTO, and I need some clarification about using EF Code First and DTO in n-tier scenario with WCF.
Let's look a these classes:
public class Order
{
public int Id { get; set; }
public DateTime ShipDate { get; set; }
public ObservableCollection<OrderDetail> Details { get; private set; }
}
public class OrderDetail
{
public int Id { get; set; }
public int OrderId { get; set; }
public int ProductId { get; set; }
public decimal Quantity { get; set; }
}
When user want to edit existing order, my client application (WPF MVVM app) requests some DTO, which then being converted to Order instance. Then, user makes some changes in order through UI - e.g., changes ShipDate, removes two positions, modifies one, and adds one.
Now I want to deliver changes to the server. As far as I understand DTO concept, I need to construct some DTO type, containing info about changes has been made:
[DataContract]
public class UpdateOrderDTO
{
[DataMember]
public DateTime ShipDate { get; set; }
[DataMember]
public Collection<OrderDetail> NewDetails { get; private set; }
[DataMember]
public Collection<OrderDetail> ModifiedDetails { get; private set; }
[DataMember]
public Collection<OrderDetail> DeletedDetails { get; private set; }
}
But when, and where should I to create this DTO? I mean, I can't create it on submitting changes - there's no change tracking information in Order class.
Looks like, this object have to be created together with Order after it was requested for edition by user. This allows to track changes... Am I wrong?
Please note, that the question isn't about STEs. For some reasons, I don't want/can't use them in current project.
Thanks a lot for sharing your experience.

How to create a DTO in asp.net?

1) I want to know what is the recommended way to create & return a DTO for an object which has 10 attributes and I only want to return 2 with my DTO object.
2) Should DTO's have their own namespace ? If yes, how do we organize them ? Each DTO inside a single class file or all DTO's inside a single class ?
Please provide me some sample code.

DTOs are dumb objects composed of public getters/setters. I generally put them in a separate namespace called SomeProject.Dto.
public class CustomerDto {
public int Id { get; set; }
public string Name { get; set; }
public LocationDto HomeAddress { get; set; }
}
I generally try to keep the property names the same between the DTO and corresponding domain class, possibly with some flattening. For example, my Customer might have an Address object, but my DTO might have that flattened to:
public class CustomerDto {
public int Id { get; set; }
public string Name { get; set; }
public string HomeStreet { get; set; }
public string HomeCity { get; set; }
public string HomeProvince { get; set; }
public string HomeCountry { get; set; }
public string HomePostalCode { get; set; }
}
You can dramatically reduce the amount of repetitive mapping code of translating domain objects into DTOs by using Jimmy Bogard's AutoMapper.
http://automapper.codeplex.com/

Your question is very open ended. The answers are dependent on the scale of your application.
In general I create my DTO's or ViewModels in their own assembly. To get my DTO's I have some service layer take care of creating them based on my request.
If you want concrete examples take a look at some of the Asp.NET MVC examples at asp.net. While you may not be using MVC you can at least see how the ViewModels are created.

DTO shape: flat, complex/nested, or a mixture of both

I have an MVC2 n-tier application (DAL, Domain, Service, MVC web) using a DDD approach (Domain Driven Design), having a Domain Model with repositories. My service layer uses a Request/Response pattern, in which the Request and Response objects contain DTO's (Data Transfer Objects) to marshal data from one layer to the next, and the mapping is done via help from AutoMapper. My question is this: what shape should a DTO typically take? Can it have nested/complex DTO's as well or should it strictly be a flat projection? Or possibly a mixture of both? Also, what are the main reasons for having a flat DTO vs a more complex/nested DTO?
For instance, suppose I had a domain such as the following:
public class Employee
{
public string FirstName { get; set; }
public string LastName { get; set; }
public Company Company { get; set; }
}
public class Company
{
public string Name { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string State { get; set; }
}
There are three different ways I've thought of modeling the Response object.
Option 1 - the DRYest option:
public class GetEmployeeResponse
{
public class EmployeeDTO { get; set; } // contains a CompanyDTO property
}
From the research I've done, it would be inappropriate for a DTO to take a similar shape as the domain object(s) as demonstrated above.
Option 2 - a flattened projection of the domain (anti-DRY):
public class GetEmployeeResponse
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string CompanyName { get; set; }
public string CompanyAddress { get; set; }
public string CompanyCity { get; set; }
public string CompanyState { get; set; }
}
This is more simple, like a DTO apparently should be, but ultimately makes for more DTOs.
Option 3 - a mixture of both:
public class GetEmployeeResponse
{
public EmployeeDTO Employee { get; set; }
public CompanyDTO Company { get; set; }
}
This allows for the code to be a little bit more dry, reusable and manageable, and doesn't expose my domain structure to the end user. The other main benefit is that other responses, like GetCompanyResponse could simply return CompanyDTO, without having to make a copy of all those properties, similar to option 2. What do you think? Which option of these (if any) have you taken and/or have worked for you? If these Request/Responses later get exposed as WCF service methods, does your answer change?

My personal preference would be to try and keep it flat as possible with only the required data being transfered. having said that I have used deeply nested DTO in the past because it made sense at the time and fitted the requirements. so I guess it comes down to "it depends". At the end of the day go with what makes sense for the application at hand. No point trying to shoe horn data into a DTO convention that doesn't fit what you are tying to achieve.