Timeline for Is There a Real Advantage to Generic Repository?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 7, 2012 at 17:36 | comment | added | Eric King | @Telastyn Yes, I would agree with that, but it happens with specific repositories, too. Leaky abstractions are not specific to generic repositories. (Wow, could I have phrased that any more clumsily?) | |
| Sep 7, 2012 at 17:31 | comment | added | Telastyn | @EricKing I have too, and it was good there, but it tends to leak some abstraction since the common stuff tends to only exist due to commonality of how the data is stored (GetByID for example requires tables with IDs). | |
| Sep 7, 2012 at 17:06 | comment | added | Eric King | There's no reason you can't have specific repositories that delegate the common stuff to a generic repository, but also have additional repository-specific methods for more complex calls. I've seen it done that way several times. | |
| Sep 7, 2012 at 2:23 | comment | added | Telastyn | @sam - I tend to favor more specific repositories, yes. If they're doing translation or not depends on where things are likely to change. If your domain is well defined, I'd return things in the shape of the domain. If the data is well defined, I'd return things in the shape of the data structures. If neither are, I'd have an entity that serves as the well defined basis to build off of and then adapt to/from that. | |
| Sep 7, 2012 at 2:16 | comment | added | Sam | So it makes more sense to have a Repository per data object, or group of tightly related objects, with specific methods like GetById(int id), SortedList(), etc? Am I returning lists of data objects from a repository, or transforming them to business objects with the necessary fields as well? Kinda thought that was what happened in the Service/Business layer. | |
| Sep 7, 2012 at 1:56 | history | answered | Telastyn | CC BY-SA 3.0 |