Last post Aug 04, 2014 07:49 PM by jammycakes
Jul 27, 2014 02:30 AM|jasminder.33|LINK
Jul 27, 2014 11:16 AM|Yorrick vd Voort|LINK
The reason why it is stated like so is that when you use the entities that are auto generated by the Entity Framework (EF) with Database first you will be tightly coupled to EF. The remark that it is only useful when using POCO classes mapped with Code First
is not necessarily true. Yes, if you use the POCO classes with Code first you’re not tightly coupled to EF and you won’t have to do some additional mapping but when you use the auto generated entities and map those in the repository to POCO classes you’re
also not tightly coupled to EF. As long as you use the POCO classes in all layers of your solution and do the mapping in the Repository you're safe.
Hope this helps.
Jul 28, 2014 12:34 PM|jasminder.33|LINK
Thanks for the reply yorrick.
It seems that if we use EF as well as POCO classes, it also leads to lot of extra code, which would not have been required if it was simply code first approach. Am i correct ?
Jul 28, 2014 02:35 PM|Yorrick vd Voort|LINK
A lot of extra code is a bit exaggerated. The only thing you have to do is map the POCO classes to the Entities from EF and visa versa. Agreed if you use EF code first you would have the POCO classes from the get go and you won't have to map them.
The choice you're gonna make really depends on what you like. If you're used to start designing your database first, really know what the data model looks like and know for sure you won't change the data model then use database first. If you're not sure
what the data model will look like and need to make changes on the fly without wanting to do a lot of table and column creation/work in the database manager you could opt for code first. But remember that some things in code first don't come as easy as doing
it in the database manager.
Jul 28, 2014 05:08 PM|jammycakes|LINK
Yorrick vd Voort
The only thing you have to do is map the POCO classes to the Entities from EF and visa versa.
Don't map your entities to POCO classes unless you have a very, very, very convincing reason for doing so. I really can't stress this enough: it's a horrible, horrible practice. It violates DRY, it increases the risk that you'll make a mistake,
and it causes a lot of friction, especially when you start introducing relationships (parent/child, many-to-many etc) into the mix.
Aug 04, 2014 02:07 PM|Yorrick vd Voort|LINK
Don't map your entities to POCO classes unless you have a very, very, very convincing reason for doing so
One convincing reason is that you don't always want to show/use all properties from an entity in a layer or view. This has nothing to do with DRY or making mistakes. Mistakes are made when you don't take care and don't pay attention, hardly a reason not
to do it.
Regarding it not being DRY:
I.e. A Person entity with properties like ID, Name, Last name, bank account number, account balance, etc, etc.. and a View that only shows Name and Last name. In this case you don’t send the entity to the View but a view model that contains only Name and
Last name. This example goes for any layer. Mapping is done based on the needs of the functionality. Even when all properties of the entity are needed you map them, just if it were only for the reason of being loosely coupled (it’s not a sin). Be in the driver
seat of your application and be loose and separate concerns.
And of course this all depends on the application’s needs. If it is a small app, that is not business critical, then by all means use the EF entity throughout all layers, hey just use the EF context in the controller directly, time is money after all (not
being sarcastic). But if it is a business critical app just map the entities before they leave the DAL (in case of database first). Or just use EF code first and basically the mapping is already done, either way there is some sort of mapping and personally
I have never faced issues with many to many relationships while mapping Entities to DTOs.
If I’m mistaken I’d really like to see examples so that I can learn from my mistakes and misunderstandings. (again not being sarcatisc)
Thanks and regards,
Aug 04, 2014 07:49 PM|jammycakes|LINK
This has everything to do with DRY and making mistakes.
What I mean is this. One of the most common changes you have to make to your model is to add a new property to an entity, and a corresponding column in the database. If you are mapping entities to DTOs, you are increasing the number of places in your codebase
that you have to change in order to implement this. This means that (a) you have to keep more pieces of information in your head at once, (b) the chances of you making a mistake increase significantly, and (c) you have to jump through more files in your codebase
to get a handle on what is going on. All in all, you are just making things harder for yourself and slowing down development. Depending on how you implement it, you are also almost certainly locking yourself out of important features of your ORM that you need
to handle concurrency, or lazy versus eager loading, or caching, to give a few examples.
Now, about loose coupling and separation of concerns. It's important to realise that these are a means to an end, and not an end in themselves. They need to have a tangible
business benefit, in terms of making your code easier to work with, or more robust, or facilitating specific requirements that your client is actually asking for. You should never do something the hard way just because your project is business critical.
If your separation of concerns is high-maintenance, or adversely affects performance, or makes common user stories hard, and if its only benefits are non-functional requirements that the business is not asking for, then to all intents and purposes, you are
stealing from your client.
This article by Kent Beck gives a good explanation of when a separation of concerns is likely to be helpful and when it's likely to be high maintenance. Different
parts of your application are good candidates for separation of concerns if they can be reasoned about (and therefore changed) independently of each other. One implication of this is that the BOL/BLL/DAL/presentation layers are not good candidates for separation
of concerns, as they can not be reasoned about independently.