Question

Is creating a Repository pattern implementation on top of Linq to Sql a good design for a medium size public faced web application?

The app only deals with Sql sever backend and it requires rapid development

I really like LINQ2SQL since it’s a neat DAL. I thought of EF but it’s too much for this project.

Many thanks in advance for the suggestions.

Answer 1

A large tenet of DDD, from which repository pattern originates, is to create an application which can evolve “easily” over its lifespan. In the future, you may find that Linq2Sql is inadequate for your needs, or (more likely) that the technology was retired (as Linq2Sql would be in favor of EF), etc. Using the repository pattern means you are writing application code against a solid, well-known concept, in an abstract fashion. The actual implementation is hidden from your various application features, meaning you can swap them out in the future as needed.

There are other benefits, too, like allowing a component that uses a repository to be used independently of its environment. Say you have a component that uses a repository, and then you find that you need to be able to use this component in a service to do nightly jobs. You could create a service that uses the same code, but uses an implementation of repository that interacts with a web service, rather than the database. You wrote the code once, just flipped some switches.

Another big reason is unit testing. You don’t need to unit test that your ORM or persistence API works, you need to unit test that your application that would otherwise interact with persistence works as expected.

So yeah, I think it’s good design.