Your idea is correct. Perfectly acceptable to call business logic from View Model. I do it all the time.
Unfortunately, your current implementation is strongly coupled to concrete types. You could use a little abstract refactoring:
In stead, in your Business layer, create an Interface, IEXFacade to pass bind your object and pass to your ViewModel:
public interface IEXFacade
{
public IEnumerable<SomeModel> GetMonthlyCollection(int SelectedYear, int SelectedQuarter);
public IEnumerable<SelectListItem> GetFinancialYears();
public IEnumerable<SelectListItem> GetFinancialQuarters();
public int getSelectedYear();
public int getSelectedQuarter(DateTime dateTime);
}
and your EXFacade definition would look something like:
public class EXFacade : IEXFacade
{
private TimePeriods _timePeriods = new TimePeriods();
public int getSelectedYear()
{
return DateTime.Now.Year;
}
public int getSelectedQuarter (DateTime dateTime)
{
return _timePeriods.GetQuarterNoForDate(dateTime);
}
public IEnumerable<SomeModel> GetMonthlyCollection()
{
....
return MonthlyCollection;
}
public IEnumerable<SelectListItem> GetFinancialYears();
{
....
return MonthlyCollection;
}
public IEnumerable<SelectListItem> GetFinancialQuarters();
{
....
return MonthlyCollection;
}
}
Now your View Model would take IEXFacade and would be more tolerant of change
public class MyViewModel
{
MyViewModel(IEXFacade facade)
{
Years = facade.GetFinancialYears();
Quarters = facade.GetFinancialQuarters();
SelectedYear = facade.getSelectedYear();
SelectedQuarter = facade.getSelectedQuarter (DateTime.Now);
Collection = facade.GetMonthlyCollection(SelectedYear, SelectedQuarter);
}
//Keeping the Facade Object seems extraneous (unless I'm missing something)
//private Facade _Facade;
public IEnumerable<SomeModel> Collection { get; set; }
public IEnumerable<SelectListItem> Years { get; set; }
public IEnumerable<SelectListItem> Quarters { get; set; }
public int SelectedYear { get; set; }
public int SelectedQuarter { get; set; }
}
The goal is to de-couple dependence on your specific implementation of your EXFacade class by passing an interface. Now your EXFacade methods logic can change without breaking your view model. As long as the Interface (properties and signatures) remain the same.
Conclusion:
I'm not partial to calling logic directly from my ViewModel, as opposed to my Controller. But, it's often more convenient as it saves a step. Conversely, logic injected directly into your model is less obvious than if you consolidate it into your controllers. But the argument about "Fat Controllers" vs "Fat Models" is pretty even sided and I don't think either side is more correct.
What's more important is to understand that the Facade Pattern is meant to be an interface between your "Chatty" Logic Layer and your Presentation Layer. For the sake of Abstraction and de-coupling, the pattern calls for an Interface. As soon as you abstract your Facade with an Interface you can further de-couple by using an IOC container like NInject to Inject your Facade into your controllers or Models.
I strongly recommend using the Dependency Injection pattern in a large project like this.