2 Replies - 1381 Views - Last Post: 23 February 2018 - 12:16 PM

#1 andrewsw   User is online

  • never lube your breaks
  • member icon

Reputation: 6795
  • View blog
  • Posts: 28,083
  • Joined: 12-December 12

Service Layer and/or Repository Pattern

Posted 23 February 2018 - 02:57 AM

I have been reading about these topics for a while but remain puzzled. Here are relevant articles:

Is the repository pattern useful with Entity Framework Core?

Six ways to build better Entity Framework (Core and EF6) applications

1) What is the difference between the Repository Pattern and Service Layer? To me it seems that they are, or at least could be, the same thing.

2) What about the Business Layer? Is this a separate code layer below the Service Layer? (It is mentioned often but I haven't encountered (yet) a clear code example.)

3) What comments do you have about the Repository Pattern? To me, it seems that it potentially results in duplication of what Entity Framework already provides: possibly a Repository (and interface) for each Entity. [I am aware of the option of creating a generic repository, but this itself can end-up being tweaked too much.]

Is This A Good Question/Topic? 0
  • +

Replies To: Service Layer and/or Repository Pattern

#2 astonecipher   User is offline

  • Senior Systems Engineer
  • member icon

Reputation: 2853
  • View blog
  • Posts: 11,182
  • Joined: 03-December 12

Re: Service Layer and/or Repository Pattern

Posted 23 February 2018 - 10:30 AM

I can't definitively give you an answer coherently. What I can suggest is the PluralSight course, Domain Drive Design Fundamentals, it goes into this and may give the info you are looking for.
Was This Post Helpful? 1
  • +
  • -

#3 Skydiver   User is online

  • Code herder
  • member icon

Reputation: 6917
  • View blog
  • Posts: 23,515
  • Joined: 05-May 12

Re: Service Layer and/or Repository Pattern

Posted 23 February 2018 - 12:16 PM

My opinion is that if you are going to use Entity Framework, you better be using EF6 or higher, and you don't really need to apply a repository pattern unless you need even more abstraction than what you currently get with the entities exposed by EF.

Unfortunately, in my job, I often get to peek at a lot of other people's code (because they end up complaining that the IIS servers that we run is "slow" or "non-performant" or that their AJAX calls keep timing out). When I see their code, I cringe because even though they are using EF, the entities that they are exposing are database records, not domain entities. They then wrap map that EF entity into a domain object within their DAL (data access layer). More often, than not, it's a straight through "leaky" domain entity that actually knows about table key ID values. Yes, It's amateur hour at a Fortune 50 company that handles yours and my health care data. *sigh* All I can do is point out the inefficiency of all this. They simply need to redesign so that they take full advantage of EF. (The irony here is that I'm a No-SQL guy who is completely against Entity Framework regardless of version, and I'm suggesting using EF more efficiently.)
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1