ctolkien/gist:4248180

## gistfile1.txt
Overall thoughts - the size of the sites we're working on are not huge, and not complex. A lot of the more complex patterns do not apply.


RE: Multiple projects. I've now come to the descision that splitting out sites into "Core, Web, Data" etc. type projects is something that has persisted from the ASP.Net 1.0 days and isn't needed anymore. Our sites almost never need re-usable components. We never (for instance) have needed to use the data component of a site in a different project. IF we did, we'd know about it up front and could design for it appropriately. Thus, multiple projects is not required. This was one of the points made in the ASP.Net MVC 4 Pro book.

RE: Repository Pattern

Repository offers a few distinct benefits.

a.) does not tie your application to a certain type of persistance.

b.) allows you to test with mock implementation.

c.) used in a DDD context (which is not applicable for the size of the sites we build)

Using an ORM like EF is already a "repository" or softs. It abstracts away some of the persistance mechanisms... meaning you could swap to Oracle should you need to. You couldn't, however, swap to a entirely different database model (like something NoSQL).

In theory, the repository pattern allows you to swap out your relational database for antyhing else. In reality however, basing your system around a RDBMS would have already leaked into your design. You cannot swap out a RDBMS for a NoSQL option just by changing the repository - it won't work effeciently.

Using a generic repository also means that you lose the particular advantages of your persistance method of choice.

Ayende hammers home the point here:
http://ayende.com/blog/3955/repository-is-the-new-singleton


Service Layer -

Logic still needs to go somewhere, Service layer should abstract any of the queries / logic required to operate against the system. This:

a.) keeps it out of the controllers

b.) gives us a chunk that can be unit tested


Given the size and style of the projects we work on, I feel that the best design looks like so:

Controllers -> Services -> EF -> Database.

We still use interfaces rather than concrete classes so we can stub in fake implementations for testing, but we accept that we're running on EF as a dependency and don't try and hide that away.
	Overall thoughts - the size of the sites we're working on are not huge, and not complex. A lot of the more complex patterns do not apply.


	RE: Multiple projects. I've now come to the descision that splitting out sites into "Core, Web, Data" etc. type projects is something that has persisted from the ASP.Net 1.0 days and isn't needed anymore. Our sites almost never need re-usable components. We never (for instance) have needed to use the data component of a site in a different project. IF we did, we'd know about it up front and could design for it appropriately. Thus, multiple projects is not required. This was one of the points made in the ASP.Net MVC 4 Pro book.

	RE: Repository Pattern

	Repository offers a few distinct benefits.

	a.) does not tie your application to a certain type of persistance.

	b.) allows you to test with mock implementation.

	c.) used in a DDD context (which is not applicable for the size of the sites we build)

	Using an ORM like EF is already a "repository" or softs. It abstracts away some of the persistance mechanisms... meaning you could swap to Oracle should you need to. You couldn't, however, swap to a entirely different database model (like something NoSQL).

	In theory, the repository pattern allows you to swap out your relational database for antyhing else. In reality however, basing your system around a RDBMS would have already leaked into your design. You cannot swap out a RDBMS for a NoSQL option just by changing the repository - it won't work effeciently.

	Using a generic repository also means that you lose the particular advantages of your persistance method of choice.

	Ayende hammers home the point here:
	http://ayende.com/blog/3955/repository-is-the-new-singleton


	Service Layer -

	Logic still needs to go somewhere, Service layer should abstract any of the queries / logic required to operate against the system. This:

	a.) keeps it out of the controllers

	b.) gives us a chunk that can be unit tested


	Given the size and style of the projects we work on, I feel that the best design looks like so:

	Controllers -> Services -> EF -> Database.

	We still use interfaces rather than concrete classes so we can stub in fake implementations for testing, but we accept that we're running on EF as a dependency and don't try and hide that away.