Architectural decisions: ASP.NET MVC & Entity Framework

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 Framewo

Answer 1

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.