Timeline for Effective Repository in C# - Where to put methods?
Current License: CC BY-SA 3.0
7 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jul 31, 2014 at 16:09 | comment | added | Robert Harvey | Actually, the abstraction that provides a 1 to 1 mapping to your database tables should be the ORM. The Repository (or Service Layer) should have methods that relate to units of work, such as completing an order or transferring funds. | |
Jul 31, 2014 at 14:51 | comment | added | ravibhagw | @MetaFight Based on my actual situation, the concept of a "Ticket" is an abstraction. The actual problem domain has several ticket types (Incident, Problem, Change, Request). Might it make more sense to create a TicketRepository that provides access for all four types of tickets? | |
Jul 31, 2014 at 14:39 | comment | added | Eric King | I'm with @MetaFight. "Defining your repository based on your requirements for this specific application" is exactly how it should be done. I also consider "repository per table" as an anti-pattern, since it doesn't really deal with the application's needs, unless the application is of the simplest "forms over data" form. | |
Jul 31, 2014 at 14:36 | comment | added | devnull | @MetaFight abstracting the persistence layer is one of the things repository is used for | |
Jul 31, 2014 at 14:25 | comment | added | user441521 | I guess that's why I put table in quotes. They don't have to be an actual DB table (but usually in my case they are), but they are application "tables". He seems to be wanting to group these "tables" together. I still think they would be separate and used in a service. Anything can change at any point which would require changes somewhere. | |
Jul 31, 2014 at 14:06 | comment | added | MetaFight | I see it the other way around. My understanding is that the Repository Pattern is a DDD pattern. As such, you're trying to create a useful abstraction for fetching Domain Entities. Since your DB doesn't necessarily need to model 1-table to 1-entity creating a repository per table seems like a bad idea. You'd essentially be coupling your repositories to your DB implementation (which could change) instead of your Domain Model. | |
Jul 31, 2014 at 13:42 | history | answered | user441521 | CC BY-SA 3.0 |