Where to locate Model classes in ASP.Net MVC

[oldman]

We have a business layer in a separate project that does CRUD, reporting, caching, and some extra logic. We aren't going to be using EF, or something similar. Currently we've defined c# classes as MVC Models, and our controllers call the business layer to populate the Models, which are currently defined in the usual place in our MVC app. These C# models get serialized as JSON, and we use the mapping plugin to make KO ViewModels.

Since everything we do in the browser is c#/JSON based using knockout, we aren't using MVC models in the traditional MVC way - everything gets posted as JSON and serialized to c#, so we don't use MVC model binding, validation, etc. We're considering moving these models into our business layer to simplify things and allow us to test the business layer independently from the web app. It also opens up the possibility of using the business layer in other web apps.

So we'll be left with an MVC project that has controllers and views, but no models - controllers will call into the business layer to get their models, which will be in a different namespace. We're nervous about departing from the normal MVC structure, but a KO/javascript based client is fundamentally different from a DOM based client that MVC was originally built around, so maybe it makes sense.. 

Does this sound like a viable way to go? Is there a better approach?

[Chris Marisic]

Domain models are always first class citizens and always go in a separate project. The only models I ever have in a MVC project directly are view presentation models.

We use KO and still use model binding, validation. We've created extensions to the html helpers to give first class support for databinding syntax so we still get all the utility of LabelFor/TextBoxFor etc for creating our once and only once for all purposes. Which also allows us to leverage the integration with JQuery unobtrusive validation.

We also avoid making a separate ajax call to get data when we bring back the html to the client, for initial loads we bring back the model converted to json embedded directly in the page. After that page load is when we then proceed with pure ajax calls.

We build our applications that functionality is contained in single page application silos. Instead of trying to cram every single thing into 1 page which I find to be an anti-pattern for the amount of crap management you have to deal with we serve physical pages at logical transition points, ie when the resource you want to view/edit/create changes.

Why should /users have any knowledge of /posts? To bind those together in a SPA is why I feel that is an anti-pattern. SPA is a large violation of the SRP and requires too much monkeying with assets that are currently unneeded. For a mobile device theoretically a true SPA might be beneficial, but outside of mobile I find no benefit whatsoever to a monolithic SPA app.

Also view my recent comment: https://groups.google.com/d/msg/knockoutjs/zT03Y8t6AFk/JFMTjhXs46AJ as you might this relevant as this was in response to another ASP.NET MVC user.

[Scott McKissock]

We do things similarly - our app is a collection of SPAs (if that makes any sense) with edits happening via asynchronous posts. We have a bunch of custom ko bindings to do strange things... 

We have domain models in a separate project, with C# instances in the web app that get constructed by calling into the domain layer. These are serialized to JSON and become our ViewModels. It occurred to us that these are typically identical to the domain objects, so defining them separately in the web app wasn't buying us anything.  We could also code gen these, but why?

So it looks like we're going to have the controllers get ViewModels directly out of the domain layer, and remove the models defined in our MVC apps altogether.  It seems like a weird thing to do (violating separation of concerns), but it makes sense for us because we're often just doing CRUD.  And it will make testing easier.