overcomplicating things with the repository pattern

The Repository pattern was used in a project by some team members 6 or so months ago and it's being mentioned again along with concepts of an Aggregate Root in discussions on refactoring another project.  Both of these projects were C# projects using LINQ to SQL.   While working on the first project I kept thinking that the repository pattern seemed to just over complicate things and I couldn't see what real benefit it brought to a fairly simple application.  Now, I've done some further reading on Aggregate Roots and found ties to the repository pattern again.  As I read through several definitions I kept thinking that the main benefits are already provided via LINQ and implementing it on top seemed to only add another abstraction layer.  I did some more searching on the subject and found this article: Repository is the new Singleton and it just echoed everything I was thinking.

Creating a repository for data that is already in your DB is overkill when you are using LINQ (and likely any modern ORM) for accessing that data since the data access provided by LINQ is itself making use of the repository pattern .  A good place where the repository pattern would be useful is where you may have different sources of data.

Here is another interesting article about the Purpose of the Repository Pattern that talks about some of the issues when using this pattern along with LINQ.  The DataContext issues he mentions exist generally in a Web Application built on LINQ and not just when using repositories.  Our team got around some of the DataContext issues by using a DataContext Factory that we found that creates a scoped DataContext within the HttpContext and while within the scope of the HttpContext it always returns the same DataContext.  This helps keep anything within the HttpRequest in the same Unit of Work.  It was also written to work within the current thread if a HttpRequest is not available (a non-web app).

Design Patterns vs. Architectural Patterns

After discussing MVC and it's use (or non-use, actually) in some of our apps it became apparent that a bigger problem existed in the design of these applications. Now most of our apps are used in house and were developed initially by a group of bygone developers and as part of the ongoing task of trying to enhance and adapt them we are reminded of the benefits of a strong attention and adherence to good design.

Despite being written in an Object Oriented language, much of the functionality in these applications is accessed through static methods and the model classes are nothing more than containers. When model objects tend to be simple containers we get this confusion about what the controller actually is. If all appropriate code were actually in the model classes the division would be a little clearer. LINQ makes things a little easier because it creates a bunch of your model for you and you can build on it using partial classes and such. The problem persists in LINQ apps though where if developers don't follw good OO design we can have all these static methods adding another layer of complexity to everything.

There is an article on implementing MVC in ASP.Net that outlines it pretty well. The part I don't like is that the model is not object oriented but uses static methods. It is still a good reference though. So in the context of ASP.NET, the way I see it is that the code behind is the controller and basically everything else that is not an aspx page is the model.

Both Design Patterns and Architectural Patterns will improve the quality of code when applied. It follows that using them together will yield even better results.