c# - What is the different between Model/Business Layer/Data Access and Repositories in the MVC architecture? -


i start question stating new .net framework , asp.net altogether. however, trying learn asp.net 5 mvc 6. have read many tutorial me speed. main tutorial have learned lot "learn mvc in 7 days"

i think mvc architecture on all, there terminology/layers confusing me i.e. model, business logic layer, data access layer , view model.

here overall understanding of mvc architecture "please correct me if wrong"

  • (m) model: object represent database table. each table in database model. each column in each table attribute in model's object. example, if have table called "users" following columns id,firstname,lastname , username model called user , "id,firstname,lastname , username" attributes.
  • (v) view: way present data end user placing data html page.
  • (c) controller: layer called route engine. controller class holds logic on data/views should user see. example, userscontroller class has method called index() request data user model , returns view called showallusers.

however, model seems have 3 layers underneath so

  • view model: seems way transform raw data coming model presentable "view ready" format. example, if want present user's full name end user not have fullname attribute in model. layer create new object same @ model object 1 additional virtual attribute called fullname. therefore, can display obj.fullname in view.
  • business logic layer
  • data access layer

additionally, if want have repository controller, fit here? understand may not necessary small application, trying understand , learn correct way can decide whether needed in app or not.

my question here business logic layer , data access layer? , repository fit here?

i appreciate explanation example.

the following snippets pulled tutorials on msdn, may find helpful:

data access layer

when working data 1 option embed data-specific logic directly presentation layer (in web application, asp.net pages make presentation layer). may take form of writing ado.net code in asp.net page's code portion or using sqldatasource control markup portion. in either case, approach tightly couples data access logic presentation layer. recommended approach, however, separate data access logic presentation layer. separate layer referred data access layer

business logic layer

the data access layer (dal) created in first tutorial cleanly separates data access logic presentation logic. however, while dal cleanly separates data access details presentation layer, not enforce business rules may apply. example, our application may want disallow categoryid or supplierid fields of products table modified when discontinued field set 1, or might want enforce seniority rules, prohibiting situations in employee managed hired after them. common scenario authorization – perhaps users in particular role can delete products or can change unitprice value. in tutorial we'll see how centralize these business rules business logic layer (bll) serves intermediary data exchange between presentation layer , dal.

from code project article, found description of data access layer's purpose particularly informative:

the data access layer provides centralized location calls database, , makes easier port application other database systems.

i located this blog post excellent job of illustrating how business logic layer integrates repositories:

enter image description here

finally, here microsoft's definition of business logic:

business logic defined application logic concerned retrieval, processing, transformation, , management of application data; application of business rules , policies; , ensuring data consistency , validity. maximize reuse opportunities, business logic components should not contain behavior or application logic specific use case or user story.

i wish provide own expert description of these layers, learning subject thought share had uncovered in hopes we'll both able learn it. example problems related these layers, please refer tutorials have linked above.


Comments