locked
MVVM with Service layer - where should Business logic go? RRS feed

  • Question

  • Hi all,

    I'm looking at designing a new application using MVVM (with Prism). I'll have a WPF client application front end, but I want to centralise my DB, and marshal all DB calls through a WCF API (i.e. I don't want my clients to know about the DB directly, so that I can manage/change technologies as I wished).

    Additionally, I may want to create an API that third parties can use, which would hook into my internal API.

    Given MVVM, I'm not 100% sure where the business logic should go. All the examples I have seen of MVVM tend to have all the business logic directly in the VM itself.

    As a specific example, see the below (aircoded) code:

    public class ViewModel
    {
      public Model ThisModel {get; set;}
      public string ErrorMessage {get; set;}
      private _service = new Service();
    
      public void Save()
      {
        if (ValidateModel)
        {
          _service.Save(ThisModel);
        }
      }
    
      public bool ValidateModel()
      {
        if (_service.DuplicateName(ThisModel.Name, ThisModel.Id))
        {
          ErrorMessage = "Name already exists";
          return false;
        }
      }
    }
    
    public class Service
    {
      public bool Save(Model model)
      {
         //Call DB Save Method.
      }
    
      public bool DuplicateName(string name, int id)
      {
        //return true if name already in the DB
        //and not associated with the specified id.
      }
    }

    In this example, you can see that the Validation is happening in the VM, the Service layer is performing basic DB related functions. This seems in keeping with the examples I have seen around MVVM - they create a repository class that handles the data saving/loading (here i'm just using the WCF service instead).

    But if I were to implement an API for third party developers (or a website to allow the same function), I would need to re-implement the Validation Logic. Instead, I could move the Validation up into the Save Method, which would centralise the Business logic so that it was the same no matter what front end called it.

    My concern on that, is that the VM essentially just becomes a (relatively) dumb pass-through or, at best, a class that handles "UI" related logic in a non-UI manner. In which case why use MVVM?

    Can anyone give me some pointers on the best way to work with MVVM and WCF?

    Wednesday, May 29, 2013 10:55 PM

Answers

  • My advice is to put your business logic into a business dll. You can deploy it wherever you need to use it, be .net in SQL (wouldn't recommend), WCF tier, presentation tier, wherever. You VM can use the business rules if you want to validate early, and re-use if you want on the mid-tier...even data tier if you want. Just because you don't want to duplicate code, and you want to place components in the correct layer, doesn't prevent you from deploying to whatever tier you want.


    http://pauliom.wordpress.com

    Friday, May 31, 2013 8:54 PM

All replies

  • My advice is to put your business logic into a business dll. You can deploy it wherever you need to use it, be .net in SQL (wouldn't recommend), WCF tier, presentation tier, wherever. You VM can use the business rules if you want to validate early, and re-use if you want on the mid-tier...even data tier if you want. Just because you don't want to duplicate code, and you want to place components in the correct layer, doesn't prevent you from deploying to whatever tier you want.


    http://pauliom.wordpress.com

    Friday, May 31, 2013 8:54 PM
  • So if I understand you correctly, you suggest creating a "Business Logic" dll, that contains those functions.

    Thats not a bad idea, although that still requires me to decide whether I place it behind the WCF endpoint, or on the "client" side. The decision impacts whether or not I would be requiring calls to an IServiceLayer type object or an IDataAccess type object.

    I'll need to consider it, but I'd probably do it "client" side.

    Thanks for the advice.

    Fergal

    Saturday, June 1, 2013 8:55 PM