Structuring an MVC Application wityh Entity Framework and building using TDD

Question

Background

I am about to start the process of creating a new application with MVC 5 and EF6 and building it out with TDD. This is my first MVC application so i have decided to use it as a bit of a learning platform to better understand a whole range of patterns and methodologies that i have been exposed to but have only used in passing up until this point.

I started with this in my head:

• EF - Model
• Repositories
• Services
• UI (controllers views)

Removing the Repositories

I shifted this thinking to remove one layer, repositories simply as my understanding has grown i can see the EF (specifically IDbSet) implements a repository pattern or sorts and the context itself is a unit of work, so wrapping it around a further abstraction, for this application at least seems pointless, at that level anyway.

EF will be abstracted at the Service Layer

Removing the Repo's doesn't mean EF will be directly exposed to the controllers as in most cases i will use the services to expose certain methods and business logic to the controllers, but not exclusively exclude EF as i can use it outside of services to do things like building specific queries which could be used at a service level and a controller level, the service layer will simply be a simpler way of mapping specifics from the controller to the EF and data concerns.

This is where it gets a bit ropey for me

Service Layer

My services feel a little bit like repositories in the way they will map certain functions (getById etc), which i am not sure is just naturally the way they are or if my understanding of them is way off and there is more information that i can't find to better my knowledge.

TDD & EF

I have read a ton of stuff about the EF and how you can go about testing with unit wise, how you shouldn't bother as the leakyness of IQueryable and the fact that Linq-to-entities and Linq-to-objects means that you won't get the results that you intend all of the time, but this has led to simply confusing the hell out of me to the point where i have an empty test file and my head is completely blank because i am now over thinking the process.

---

Update on TDD the reason the TDD tag was included as i thought maybe someone would have an idea on how they approach something like this without a repository because that is an abstraction for abstractions sake. Would they not unit test against it and use other tests to test the query-able behavior like a integration test or end to end test? but from my limited understanding that wouldn't be TDD as the tests would not be driving my design in this instance?

---

Finally, To The Point

Is the:

• EF
• Service
• UI

architecture a good way to go, initially at least?

Are there any good examples of a well defined service layer out there so i can learn, and are they in the main a way to map certain business operations that have data connotations to some for of persistence mechanic (in this case an ORM and EF) without having the persistence requirements of say a repository?

With the TDD stuff, is it ok to forgo unit tests for service methods that are basically just calling EF and returning data and just opting for slower integration tests (probably in a seperate project so they are not part of the main test flow and can be run on a more ad-hoc basis?

Having one of those weeks and my head feels like it is about to explode.

Answer 1

Lol I've had one of those weeks myself for sure. ;)

I've had the same kind of internal discussions over how to structure MVC projects, and my conclusion is find what's most comfortable to you.

What I usually do is create the following projects:

1. Core/Domain - here I have my entities/domain model, and any other thing that may be shared among layers: interfaces, for example, configuration, settings, and so on.
2. Data/EF - here I have all my EF-dependent code: DataContext and Mappings (EntityTypeConfiguration). Ideally I could create another version of this using, say NHibernate and MySQL, and the rest of the solution will stay the same.
3. Service - this depends on Core and Data. I agree in the beginning it will look like a simple facade to your Data, but as soon as you start adding features, you'll find this is the place to add your "servicemodels". I'm not saying ViewModel as this is quite Web-ui related. What i mean with "ServiceModel" is creating a simpler version of your domain objects. Real example: hide your CreatedOn, CreatedBy properties, for example. Also, whenever one of your controller's actions grow to anything over quite simplistic, you should refactor and move that logic to the service and return to the controller what you really need.
4. Web/UI This will be your webApp. It will depend on Core and Service.

You didn't mention dependency injection but you have to definitely look at it.

For testing, you can test your Data using a SqlCompact provider that re-creates the database for each test instead of using a full SqlExpress. This means your DataContext should accept a connectionString parameter. ;)

I've learned a lot seeing big projects source code, like http://www.nopcommerce.com. You could also have a look at http://sharparchitecture.net/ although I bet you already saw that.

Be prepared to have some nightmares with complex object graphs in EntityFramework. ;)

My final advice is: find something specific to do and dive in. Too much abstraction will keep you from starting, and starting is key to practice and understanding.