Unless your project (or architect) demands that all methods of your app access a services layer, I would try and avoid using WCF unnecessarily (think of it - it means that all of your data between web server and back end goes over the wire, which has implications such as performance, serialization of data, and also potentially limits the lifespan of database connections and transactions, which can deprive such as lazy loading).
If you concur, the suggestion would be to ensure all accessible interfaces in your business layer are exposed on an interface, and then consume or inject the BLL interface directly into your controller.
You need to be careful about the word "Model" in MVC - ASP NET MVC encourages ViewModels, which are specific to the presentation tier and passed between Views and Controllers, as opposed to "Entities" which represent the more logical domain model as used by business logic and which can be tied to data persistence using an ORM such as EF or NHibernate. The MVC project template lumps everything which isn't View or Controller into "Model" which isn't necessary very helpful.
However, if you do choose to access your BLL via a WCF Services layer you still have some design decisions to make:
- Choose whether you share the back end entities on the client side, or do you instead use proxied entities.
- Choose whether you consume / inject the WCF service proxies directly in your controller, or do you create another facade layer (e.g. CAB calls these ServiceAgents). The latter would make sense if there are separate teams or vendors building the SOA side vs the Client side in order to accomodate changes to interfaces.
