Breaking apart conceptions -- Ayende Rahien at Professional .NET 2012
Why Stack Overflow recommends it
Stack Overflow users link it when debating whether layers, repositories and abstractions over Entity Framework or other ORMs are worth the cost, often as the main counterargument to the repository pattern.
Recommended by 1 people across 1 different months, 2013 to 2014.
What it is
A conference talk by Ayende Rahien (creator of RavenDB and NHibernate contributor) recorded at Professional .NET 2012 in Vienna. He argues that traditional three-layer, repository-heavy, abstraction-laden applications add needless complexity and that simpler architectures work better.
What people said
Strong rec kunjee · 2013-01 · Stack Overflow · on “Domain vs DTO vs ViewModel - How and When to use them?”
I will highly recommended this video from Ayende [this video] It will surely help to understand concept in and out and probably impact a lot of things about development and DDD pattern. It is more than few POCO objects.
Cites Hagai L · 2013-04 · Stack Overflow · on “The N-layers paradigm - is this concept wrong?”
I just saw the lecture: Breaking apart conceptions [this video] He keeps saying that the 3 layers paradigm started because of the problem with connection pooling. And NOT because of architectural considerations . Seems like a mind blowing theory. Can anybody proove or disproove this claim?
Cites likeitlikeit · 2013-04 · Stack Overflow · on “The N-layers paradigm - is this concept wrong?”
This is kind of a hard question to properly answer. The relevant piece [this video] of the presentation states that because of the databases not being designed for dozens of connections, there had to be a business layer introduced between the applications and the stored procedures in the database. I beg to differ. The idea of separating business logic, presentation and storage of state originates much earlier, namely in the 1970 or 1980, and according to Wikipedia [LINK] was developed at Xerox PARC [LINK] . Back then, of course, servers were way more expensive than they are today. However, that still didn't keep them from thinking about maintainability and other aspects of software development, n
Cites Slauma · 2013-05 · Stack Overflow · on “Most common practice for managing ObjectContext in EF”
@Savage: "Most efficient"? Keep it simple! [this video] (Start at 50:22 of the video) The guy talking there is ayende ( [LINK] ). Just to give you a viewpoint against too many layers, abstractions and against repositories. Unfortunately yet another viewpoint, because there is no "most common" pattern.
Cites grokmann · 2013-10 · Stack Overflow · on “How can Lazy Loaded entities be tested using a mock DbContext?”
@Raj: Thanks for the comment. Because the code depends on lazy loading (at the moment), I think I'll be using an integration test approach. I have repository set up as a service layer to the EF context, but it started to seem like an extra blanket. Then I ran across this talk by Ayende Rahien, "Breaking Apart Conceptions" [this video] , which has me reconsidering the architecture further.
Cites Ehsan · 2014-02 · Stack Overflow · on “More layers and performance issue”
Based on this [this video] presentation(for more detail) it seems that having unduly layers and assembly could cause performance problem. take a look at this scenario , it's about sending a message on "Contact Us" part of an application: [HttpPost] public ActionResult Create(ContactViewModel contactViewModel) { var request = new CreateContactRequest(contactViewModel); _contactService.CreateContact(request); return View(); } it is just a MVC controller action to create the contact by request response pattern, now about the service method imp in Service layer I have this piece of code: public CreateContactResponse CreateContact(CreateContactRequest request) { var response = new CreateContactRespons
Critical Sam · 2013-01 · Stack Overflow · on “Why use Repository Pattern or please explain it to me?”
Whoever comes across this should know that the repository pattern is an anti-pattern. Ayende explains why: [this video]
Critical Sam · 2013-01 · Stack Overflow · on “Groovy/Grails :: Ruby/Rails :: 2011 State of the framework”
Whoever comes across this comment notice that the first two points are architectural anti-patterns only existing for historical reasons. Ayende explains why this design is crap: [this video]
Critical Michael · 2014-07 · Stack Overflow · on “How to efficiently mock Data Contexts for Unit Testing with EF6, MVC and MOQ”
Thanks Jimmy, great info in here. I've been trying to avoid abstracting because so many discussions lead to this (tedious) video on why repositories/abstractions lead to confusing, unmaintainable code: [this video] but I think your abstract factory pattern example is really sexy so I'll give it another try!