Architectureasp.netbusiness-logicmvc
In my ASP MVC application I decided to add another Business Layer and made the model only to have properties.
All other functionality like save to db, get from db is done on this new Business layer. So now the controller will be calling this business layer and model for various operations. Is it a good approach to design like this?
I decided not to use model for this purpose because I would need a number of models for different actions. (for eg, one for edit and other for create)
What you're describing is the MVP pattern. There is a framework called WebFormsMVP specifically designed to facilitate this.
I'm not sure many will agree that it's the best of both worlds, but it is a considerably more testable way to use WebForms than putting all your code in the codebehind class.
However, putting a service layer in between your forms and your data model also achieves this, much more simply.
The problem I see with your approach is that you are building a REST API for only one consumer, your controllers, and that's overkill. Don't just add a layer just to pass data from one layer to another, there's no point, you'll be creating work for yourself for no additional benefit.
One (quick) way to make your API useful would be if it was the only endpoint your controllers (i.e. your application) ever needs. Consider this:
Suddenly your REST API has a purpose, and that is to provide a unified interface to your various data providers. Your application doesn't need to know about the Google or the Trello API, or any other data provider you might use in the future, it just needs to know about your REST API.
This design, albeit slightly more useful, is still overkill if your application is the only consumer. The whole point of building a REST API is to expose a publicly available interface for your applications to share. And the key here is exposure, your REST API will be available to the world and therefore it must be secure. API authentication and authorization are no simple tasks, if only one application uses your API, why go through all the trouble? Unless of course you want to experiment and learn. If that's the case, by all means go for it.
In any case, performance shouldn't be an issue. You'd be adding an extra layer, so obviously there will be some overhead, but whether that overhead will be significant or not depends entirely on your implementation. If your REST API is the single endpoint, then it will probably be a good idea to also be the one place where caching happens. And not just server side caching, a REST API makes browser caching a bit more easier to exploit, and if you get it right, the overall performance of your application may increase, comparing to a non REST approach.
tl;dr: Don't build stuff that don't have an actual purpose (unless you're learning).
Best Answer
That sounds like an eminently sensible decision to me. MVC is a presentation pattern, therefore business logic and persistence operations have no place in the UI layer of the application.
Ideally an MVC model is just the data you are presenting to be rendered by the view. This is not at all necessarily the same as an equivalent domain entity - for instance, the model may need to be tagged with UI validation attributes, may contain values for multiple selection, or may contain data transformed for display such as dates, currency values. or language translations. Because of this, it is sensible to make the M in MVC distinct from your business entities, and map from entities to models in your controller logic. A controller action should not really need to do anything more complicated than make calls to the underlying business logic layer and marshal the data returned into models for render.