Architectural decisions: ASP.NET MVC & Entity Fram

Question

I'm having an architectural decision-problem: We're about to build a new application and we've decided we'll be using ASP.NET MVC and Entity Framework (database first probably). In the first fases we'll only be building a web application for regular browsers, but in the future we might add mobile applications. (SOA?)

My question is now what would be the best way to build up the application architecture?

Would this be correct?

1. MvcProject
   • Model
   • View
   • Controller
2. DAL project
   • Holds edmx and T4 templates

I've been searching for examples, patterns and best practices but I can't seem to find something that fits just right.

Thank you!

Answer 1

Remember that best architecture is directly correlated with budget and timeline.

MVC will cost more than regular asp.net:

• MVC forces the developer to use 3 tiers at all times
• MVC developers are more expensive and harder to get

I assume you mean regular asp.net when you say DAL project. If this is the case then:

• ASP.NET development is faster than MVC
• ASP.NET web sites will allow you to use more complex third party grids, etc.
• Widely available talent in the USA

In Regards to mobile development it does not matter what you choose for the web site. Your mobile apps should be developed using in the native language of the device (IOS, Android, etc). Then you communicate with the app via SSL and JSON.

Answer 2

The way I normally structure my solutions (edit adapted for NuGet)

1. WebSite (MVC)
   • Controllers
   • Views
   • Content (scripts, css, images, etc.)
2. Presentation Models (for simple, projects this would be embedded in the web site)
   • View Models
   • Model mappers
3. Business Logic
   • Rules
   • Local Extensions (Web and General)
4. Data (if complex, use separate subfolder per context/repos/models)
   • Repositories
   • Entity Models
   • Data Context and configuration
5. Web Library (perhaps as separate solution available via local NuGet)
   • Extensions (to MVC/Web classes)
   • Helper Classes = Attributes
6. General Library (perhaps as separate solutions available via local NuGet)
   • Extensions
   • Helper Classes

Dependencies flow up this structure, i.e., the things above might reference the things below, but not vice versa. I would also have a separate test project per project. In some cases, I use external, shared libraries for web/general classes packaged with NuGet and hosted on a local repository.

For mobile, if you're going via the web, I would build that directly into the WebSite using jQuery Mobile and mobile-aware view engines. If you're thinking native, then I'd add a WebAPI layer that may or may not share the same view models as the web site for API delivery and develop the mobile app outside this structure against the API. Most likely the API has it's own models and sits above the business layer in a separate stack. In my current project, we have the data in a separate solution and are developing the API and web site in separate solutions, sharing models via NuGet packages.

Answer 3

It doesn't sound like your team has enough information to make the decision yet. I know that's why you're asking the question here, but you shouldn't rely on any answer you get. ASP.NET MVC and EF might be a great solution for you, but you shouldn't choose it without at least having worked through Nerd Dinner or the Music Store tutorials.

After you do that, you'll be able to answer your own question regarding architecture, and will probably uncover some additional questions as well.

Answer 4

First of all you have to decide how would you like to implement the mobile version of your site. Basically you have two options:

• Create separate views / controllers for your mobile pages. This solution is the most expensive but also the most flexible. (look at mobile support in MVC 4)
• Create responsive layout for your site ( http://jquerymobile.com/ ) Usually I prefer this option.

Normally i'm using 3 projects

• DAL
  • Contains Edmx, T4 templates
• Service
  • Service classes with CRUD operations (I'm not using repositories, because they are overkill)
  • View Models
• Web
  • Controllers, Views, ...

Answer 5

A basic strategy could contain the following:

• Data Project
  • EF Model
  • Entites/T4 generations
• Logic Project
  • Application rules
  • Logic not relating to presentation of the data
• Site Project
  • Presentation/aggregation logic (in the controllers/views)
  • Views
  • Scripts/assets
  • Models (for communication between controller and view only)
• Mobile project
  • Same stuff as Site but for a mobile target

Answer 6

I think you chosen a correct application architecture, we have also used the same application architecture in one of our projects...

MvcProject
Model
View
Controller

DAL project
Holds edmx and T4 templates