调用业务层方法

Question

I am quite new to multi-layered architecture and asp.net mvc. I would like to know which is the good practice to call the business layer method.

1) Calling the business layer method from the controller, populate a view model and pass the view model to the view.

2) Calling the business layer method directly from the view.

Please let me know the advantages and disadvantages in both methods. It would be grateful if explained "In which scenarios the either methods are used"

Answer 1

This is bordering on an opinion seeking question but I think it's worth an explanation, albeit you can find this with enough research.

Option 1 is the way to go, that much is probably +80% agreed to.

Anymore and you run into the 'it depends' answer. It depends on how much you need to break things out. Academically you should be loosely coupled with high cohesion. All well and good but in the real world there is rarely an absolute because perfect architecture is more a matter of 'just in time' design than academics, else you'll never get things into production. So you as the developer have to make the judgment call as to where you compromise (and you will).

So here's where it gets opinion based:

a) Loose coupling with high cohesion means better testability / maintainability / scalability at the expense of greater abstraction, ie more development time up front.

b) The reverse means less all the goods, but also less development time up front, aka 'just get it out the door and stop telling me (your boss) about good architecture damnit!'

A good developer is always striving for a). Problem is most of us have to balance that with making progress so we tend to slide towards b) (begrudgingly)

So for the sake of further discussion (if you're still reading)...An example of a), and there are plenty of other right a's, this is just one flavor:

Your view model is suppose to contain all the things necessary to render the UI of flavor, minimal data needed for view + functions called directly from UI. It should not represent the business logic pertaining to the domain models. Domain models should represent the data necessary to, well, represent the domain they encompass. Business logic layer, referring to that here as the service layer, should be the functions that operate on domains.

Ze example:

Lets say we have a user who has multiple accounts. There would be a User class and Account class. These are combined in a UserAccounts class (a User property and Accounts property (array).

Depending on how you decide to domain there is either a UserService class or a UserService + AccountService + UserAccountService class combo.

Then let's assume you have user (UserView class) and user detail (UserDetailView class) views. UserView is the User class + an aggregate representation of accounts (but not all details) + UI direct call functions. The UserDetailView represents the User + details of each account + UI direct call functions.

The User controller has two functions (plenty more for sure but just these for explanation), getUsers and getUserDetail.

• GetUsers calls the user serivce which returns an array of UserAccounts objects which is then passed through a model builder that returns a array of UserView objects which the controller then passes to the 'summary' view.
• GetUserDetail calls the user service which returns a UserAccounts object which is then passed through a model builder that returns a UserDetailView object which the controller then passes to the 'detailed' view.

Answer 2

With MVC your processing (like calling and populating a model) will fall within the model itself. The controller needs to be as "dumb" as possible, essentially just there to say "Okay I need THIS model and send it to THAT view"

Here is a VB.NET version of one of my models (I use a customized version of StackOverflow's Dapper ORM as my Database Layer. This is an unfinished model btw, and the population of the user info isn't contained in it yet):

Public Class UserAccount    
    Public Property Employee_ID() As Integer
    Public Property Email_Address() As String
    Public Property Location_ID() As String
    Public Property Department_ID() As String
    Public Property Company_ID() As String
    Public Property Password_Expiry() As DateTime
    Public Property Win_User_Name() As String
    Public Property First_Name() As String
    Public Property Last_Name() As String
    Public Property Message_Number() As Integer
    Public Property Message_Text() As String
    Public Property Password() As String

    Public Overrides Function ToString() As String
        Dim serializer As JavaScriptSerializer = New JavaScriptSerializer
        Dim result As String = serializer.Serialize(Me)
        Return result
    End Function

    Public Function FromString(str As String) As UserAccount
        Dim serializer As JavaScriptSerializer = New JavaScriptSerializer
        Return serializer.Deserialize(Of UserAccount)(str)
    End Function

    Public Function GetUserInfo() As UserAccount 'Returns user info as a strongly typed object from what is saved in the cookie
        Dim user As UserAccount
        Dim cookie As HttpCookie = DirectCast(System.Web.HttpContext.Current.Request.Cookies(FormsAuthentication.FormsCookieName), HttpCookie)
        Dim ticket As FormsAuthenticationTicket = FormsAuthentication.Decrypt(cookie.Value)

        user = Me.FromString(ticket.UserData)

        Return user
    End Function

    Public Shared Function Encrypt(password As String, Win_User_Name As String)

        Dim _password As New StringBuilder
        Try

           'encryption stuff happens here
        Catch er As Exception
            Return ""
        End Try

        Return _password.ToString

    End Function

End Class

Now all the controller needs to do is instantiate this model and give the data to the view