none
Should all methods be accessed through the service layer? RRS feed

  • Question

  • Our project is an MVC app with multiple layers including a repository(DAL), services(BLL) and web layers.  The services layer is used to access the repository which I believe is a common way of doing this.  The UI layer uses "page services" to aggregate the data and prepare it by putting it in a view model before it's used by the front end.  The page services layer doesn't really use and kind of service like WCF or web services.  It's really just a naming convention for these classes.

    There are places where the page service classes in the UI use methods directly from an an instance of the repository class, bypassing the services layer.  Most of these are situations where additional logic in the services(BLL) isn't necessary.  There are other places where the page service classes use methods in the services(BLL) layer which then use underlying methods in the repository class.

    Both of the these approaches work, but bypassing the services layer doesn't seem like the best idea due to the intent of the separation.  This app is multiple projects in the same solution.  It's very doubtful that it will ever become an app distributed across multiple machines.  Always going through the services layer to access the repository seems to stick to the intent of this design though.

    Part of me wants to continue using a mixture of these approaches because it's faster and easier.  The other side of me wants to develop good habits.  

    I would like to get the opinions on this from developers that are more experience than me.

     
    Thursday, August 25, 2016 2:32 PM

Answers

  • The basic idea of layered architecture:

    When you exchange the layer itself, then you don't need to touch any other code.

    So as long as you only bind against the public interface of the DAL then you can also directly use it. It imho only becomes an issue when you use more than one DAL method to built new business logic in the page services.

    Thursday, August 25, 2016 2:55 PM

All replies

  • The basic idea of layered architecture:

    When you exchange the layer itself, then you don't need to touch any other code.

    So as long as you only bind against the public interface of the DAL then you can also directly use it. It imho only becomes an issue when you use more than one DAL method to built new business logic in the page services.

    Thursday, August 25, 2016 2:55 PM
  • I don't have strong views on this as I'm not a great fan on 3-layer design. However, one argument against your pattern is security. By only allowing the service layer to talk to the DAL you can form security boundaries.

    http://pauliom.com

    Thursday, September 15, 2016 7:55 PM
  • Thanks for your perspective.  This particular point is new to me.  Will you please elaborate on the security boundary issues?
    Thursday, September 15, 2016 8:04 PM
  • Each layer has it's own security boundaries. Consider a simple 3 layer design of Pres, Biz and Data (because why not). Each runs in their own security identity Pres_sec, Biz_sec and Data_sec. Now let's apply some boundaries. The database can only be accessed with Data_sec, 'public' endpoints on Data can only be accessed by Biz_sec. etc. So if someone 'breaks into' the presentation layer at worse they can execute expected components but won't be able to bypass them.

    http://pauliom.com

    Thursday, October 6, 2016 2:55 PM