none
Entity Framework Questions RRS feed

  • Question

  • I am utilizing the Entity Framework in order to interface with some WCF services and some MVC3 websites I have built. I am using a database first approach.

    What I have created is a library that has a Data, Model, and CRUD folder. Data contains the edmx file and a partial class for my Entities that creates a ToDTO() method. The Model contains a class of each of my entities that I can pass around as an object. The CRUD contains what should be expected - common read, update and delete methods.

     

    My entities are named in the fashion of 'StudentEntity', and my DTO have a simpler name such as 'Student'. So the StudentEntity class has a method ToDTO which returns a Student object.

    And my CRUD folder has a class with name Student that contains the CRUD operations for the student entities.

     

    The confusion seems to come when I have another deleloper look over the code, they get confused on which Student they are looking at, the entity, the DTO, or the CRUD class.

    How should I change my naming scheme to make it more understandable? Also can you give me any suggestions on cleaning it up a bit. Maybe I do not need the DTO classes and can somehow use extension/reflection to not have a separate class for each ToDTO method.

    • Moved by Rudedog2 Friday, February 3, 2012 12:08 AM : move to more appropriate forum : (From:Visual C# General)
    Thursday, February 2, 2012 8:32 PM

Answers

  • Depends on what do you mean by "pass around". If there is serialization involved and the serialized object is sent somewhere, then it may very well make sense to copy into an object just the stuff you really need. On the other hand if you stay within a process boundary, it doesn't make much sense to copy part of the data into a stripped down structure and pass around that copy. It's probably better to define an interface restricting the access and typecast instead of copying.

    Unless you can include the restriction in the query in such a way that the extra stuff is not even fetched from the database. Something like (untested!)

    public static class ToDTOExtensions {
    	public static IQueryable<Student> ToDTO(this IQueryable<StudentEntity> query) {
    		return query.Select(s => new Student {Name = s.Name, Email = s.Email, ...});
    	}
    	...
    }
    
    var result = context.Students.Where(s.ID == 1).ToDTO().FirstOrDefault();
    

    You have to define the ToDTO() on IQueryable<Entity> instead of on Entity for the LINQ to Entities to understand the conversion!

    And by the way ... the other relations are not loaded unless or until you ask for them. Your code doesn't loadanything from the Course table.


    ----------------------------------
    http://jendaperl.blogspot.com
    A Perl developer in the world of C#

    Wednesday, February 22, 2012 1:57 AM

All replies

  • Hi MitchMiller,
    My suggestions are as follows.

    • Use more meaningful names for methods. 'ToDTO' is a very bad name, and if left without documentation gives the caller absolutely no idea what it actually does.
    • Don't have classes with almost identical names as this is confusing to almost anyone. Use names that differentiate what the objects do. For instance, your entity could be called 'Student', and your 'DTO' (I assume, eg. data transfer object / data layer), something like 'StudentManager'. Although with Entity, the entity objects practically are your DTO, so its almost repetitive to have a separate DTO these days, unless there is some business logic involved.

    Basically your code needs to be readable, understandable, well written, and organized. Writing code is similar to creative writing, but if someone can't read and understand your code and its flow of logic, then its bad.

    When you write your code, write with the intention that others than yourself will need to work with it, or even you might at a far date away. It seems your problem is just naming, and maybe organization.

    The bottom line though is, I don't know enough details about your project and obviously cannot see your code, so I can only give my constructive criticism and advice how I interpret your post.

    I hope this helped.


    Currently developing FaultTrack. I occassionally blog about C# and .NET.
    Hoping to become a MVP by 2013. Email: danderson [at] dcomproductions [dot] com
    Thursday, February 2, 2012 10:52 PM
  • I thank you for your input. And I understand I could pass around the Entity object - but I don't want to always send that down to a client when I'm working with websites. I like to just pass the DTO (data transfer object)

    But I thank you for your input.

    Friday, February 3, 2012 12:03 AM
  • Hi MitchMiller,

    Welcome!

    I think you can refer this link here: http://msdn.microsoft.com/en-us/magazine/ee236638.aspx

    There's WCF Data Service for EF, you can feel free to take a look at it here: http://msdn.microsoft.com/en-us/data/bb931106

    Have a nice day.


    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, February 3, 2012 8:21 AM
    Moderator
  • You might tweak the code generation and have the DTOs generated together with the entities.

     

    See http://msdn.microsoft.com/en-us/library/dd456821.aspx and http://msdn.microsoft.com/en-us/data/gg558520

     

    I'd probably rename the classes in the CRUD folder.


    ----------------------------------
    http://jendaperl.blogspot.com
    A Perl developer in the world of C#
    Friday, February 3, 2012 1:27 PM
  • Hi,

    I am writing to check the status of the issue on your side. Would you mind letting us know the result of the suggestions?
    If you need further assistance, please feel free to let me know. I will be more than happy to be of assistance.

    Have a nice day.


    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, February 15, 2012 8:21 AM
    Moderator
  • Mitch,

    I believe I understand your thinking on what you want passed around and not passed around.  Though you need to understand that your thinking is a little bit outdated.

    The Entity Object contains the data from the record and it contains some internal information about the object but you are not carrying around any scarce resources like data connections.  When you get an entity object it tracks when the user makes changes to the object.  When it is passed back you can do a simple Attach() / SubmitChanges() and if the object was changed then the database will be updated.  On the other hand, if no change was done your call results in no database round trip.

    As a result you are adding a burden to yourself by trying to pass a separate DTO and then mapping that back into the Entity Object.

    Wednesday, February 15, 2012 4:11 PM
  • Mitch,

    I believe I understand your thinking on what you want passed around and not passed around.  Though you need to understand that your thinking is a little bit outdated.

    The Entity Object contains the data from the record and it contains some internal information about the object but you are not carrying around any scarce resources like data connections.  When you get an entity object it tracks when the user makes changes to the object.  When it is passed back you can do a simple Attach() / SubmitChanges() and if the object was changed then the database will be updated.  On the other hand, if no change was done your call results in no database round trip.

    As a result you are adding a burden to yourself by trying to pass a separate DTO and then mapping that back into the Entity Object.

    It would seem to me that passing the entity around instead of a DTO would be more overhead. When thinking about web development that is a lot of extra information I am handing down the pipe when I only need to access the actual data contained in the fields. I might also not always want to send down all associations. For instance let us say that I have a Student table and there is a relationship between Student and Course tables. I might not want to hand down all the course information with the Student record. And it appears to me that EF pulls all of that out when I run a query such as.

    var result = from s in context.Students
                 where s.ID == 1
                 select s;
    Right now I would simply use my ToDTO method and return just the student object. How is that not more efficient than passing along all the other data from each relationship that particular data object might have.
    Tuesday, February 21, 2012 7:36 PM
  • Depends on what do you mean by "pass around". If there is serialization involved and the serialized object is sent somewhere, then it may very well make sense to copy into an object just the stuff you really need. On the other hand if you stay within a process boundary, it doesn't make much sense to copy part of the data into a stripped down structure and pass around that copy. It's probably better to define an interface restricting the access and typecast instead of copying.

    Unless you can include the restriction in the query in such a way that the extra stuff is not even fetched from the database. Something like (untested!)

    public static class ToDTOExtensions {
    	public static IQueryable<Student> ToDTO(this IQueryable<StudentEntity> query) {
    		return query.Select(s => new Student {Name = s.Name, Email = s.Email, ...});
    	}
    	...
    }
    
    var result = context.Students.Where(s.ID == 1).ToDTO().FirstOrDefault();
    

    You have to define the ToDTO() on IQueryable<Entity> instead of on Entity for the LINQ to Entities to understand the conversion!

    And by the way ... the other relations are not loaded unless or until you ask for them. Your code doesn't loadanything from the Course table.


    ----------------------------------
    http://jendaperl.blogspot.com
    A Perl developer in the world of C#

    Wednesday, February 22, 2012 1:57 AM