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"
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.
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
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.