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)
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.
If by model you mean domain model, then that is the place where business logic should reside. If you strip it from any business logic you get what's commonly referred to as a "anaemic domain model" (see www.martinfowler.com/bliki/AnemicDomainModel.html)
The gist is: your company has its own perception of a particular business domain. It has certain terms for entities, it prescribes certain behaviours to entities and interactions between them. The best way to model something like that is to actually create domain entity classes that have both state and (business) behaviour. Not by creating all sorts of services that suck up the behaviours that ordinarily are part of a domain entity.
If your Model is a plain retrieve and save to the DB, you don't need a separate Model class. It will be a overhead..
In case you are manipulating over your data and forming custom representation of your class to show on the View, It makes perfect sense to go with your approach. Additionally if in future you expect your Model to be filled from different sources, the approach will be a perfect case..
It totally depends upon your application design
As already mentioned MVC is just a presentation pattern and there is nothing wrong in having a business layer. However, you should not call that layer directly from the Controller, as these are supposed to be very thin and without any logic.
There are actually multiple patters that you can, it seesms the Pattern3 mentioned here suits your requirments.
Certainly an Active Record is a great start, but what about the business logic for integrity (e.g., add an order - that affects the customer's balance). I would caution about putting that in the client model, since it is not exposed as a service for reuse by other clients, other computers and so forth. I'd recommend architecting this into a middle tier or database, as I argued here.
