locked
Why only POCO with the Repository Pattern RRS feed

  • Question

  • User-1963854939 posted
    I just started with the Repository pattern. I was looking at the various implementations and found one implementation which says :

    http://blog.gauffin.org/2013/01/repository-pattern-done-right/

    "Do note that the repository pattern is only useful if you have POCOs which are mapped using code first. Otherwise you’ll just break the abstraction using the entities. The repository pattern isn’t very useful then."

    Can anybody guide why it is being mentioned so ? Any specific points to keep in mind (like the one above) while using this pattern ?
    Sunday, July 27, 2014 2:30 AM

Answers

  • User-1611549905 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, August 4, 2014 7:49 PM

All replies

  • User774448340 posted

    Hi,

    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.

    Regards,

    Yorrick

     

     

    Sunday, July 27, 2014 11:16 AM
  • User-1963854939 posted

    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 ?

    Monday, July 28, 2014 12:34 PM
  • User774448340 posted

    Hi,

    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.

    Hope this helps.

    Regards,

    Yorrick

     

    Monday, July 28, 2014 2:35 PM
  • User-1611549905 posted

    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.

    Monday, July 28, 2014 5:08 PM
  • User774448340 posted

    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,

    Yorrick

    Monday, August 4, 2014 2:07 PM
  • User-1611549905 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, August 4, 2014 7:49 PM