Where to write Database and Business logic in MVC?

views:

150

answers:

+3 Q:

Where to write Database and Business logic in MVC?

Hi All,

As I am learning and working on Asp.Net MVC application, I want to know that what is the better place to write Business Logic and Data Access logic in MVC.

Where should I write DataAccess and Business Logic among three layers (Model, View and Controller) ??

Could anybody please tell me the correct way to write the code for this.

Scenario: I want to retrieve all the employees where employee name like 'Mi%' ( I have SQL procedure to execute and retrieve the data.)

PS: Want to know that where I should create instance of Business Logic class and where I should create instance of Data Access layers class?

Thanks in advance.

+2 A:

Business logic should be in the Model.

Data Access can either be its own later your Controllers call, or automated in an ORM that your Controller will call through repositories.

A walk-through covering this can be found in Nerd Dinner, look for the free download section.

blu 2010-09-09 18:04:48

Thanks Blu, Just want to know where where I should create instance of Business Logic class and where I should create instance of Data Access layers class ?

nunu 2010-09-09 18:13:06

DAL classes are going to be created in the Controller. If your BLL classes are a layer on top of your DAL then the Controller will create those instead, and the BLL will create the DAL components it needs.

blu 2010-09-09 18:17:51

@nunu: Don't think of business logic as "a business logic class" but instead as logic baked into your models. Part 3 of the Nerd Dinner tutorial has some basic examples: http://nerddinnerbook.s3.amazonaws.com/Part3.htm

David 2010-09-09 18:19:03

The UI, BLL, DAL approach is not typically used in MVC in my experience. Business logic is rolled into the Model, and the DAL is implemented in an ORM that is made accessible through repositories. There is probably going to be a shift on your part in terms of architecture, and the pdf will help a lot. To get you started you can use your BLL/DAL classes in your controllers and refactor as you learn more about MVC.

blu 2010-09-09 18:21:54

@blu In a well structured application you should be able to swap out MVC for WCF or any other UI/access strategy and the logic will all still be there. If you wrap logic into your view models/controllers you've violated this.

Ryan 2010-09-09 19:29:03

I agree with Ryan on this, a well structured webforms app should be easy to migrate to MVC provided that the Service/BLL/DA layers are separated out.

Simon Hazelton 2010-09-09 20:25:27

@Ryan "swap out MVC for WCF"?

blu 2010-09-09 20:27:06

@blu Not something you'd actually do, but say you have an MVC interface and you need to drop Silverlight in on a page. You should still be able to get to the application logic through WCF with Silverlight the same as if you were on an MVC page. This primarily applies to enterprise applications.

Ryan 2010-09-09 20:40:22

@Ryan I am still trying to understand the purpose of your comment and what it adds that my answer did not cover. Also presumably you down voted my answer as well and am trying to figure out why.

blu 2010-09-09 23:19:49

@blu I did not down vote you.

Ryan 2010-09-10 04:42:48

The view is where you put your interface code.

The Controller is the place that connects the view with the model.

The model stores business logic and possibly database access. (Some ORM Layer can be used aswell)

Mark Baijens 2010-09-09 18:12:54

+3 A:

Business logic (BL) and data access (DAO) should be in separate layers. Models should only keep data and contain no logic. Controller should only receive data from view and send it to BL layer (or send from BL to view).
It's not a strict rules, but most recently used approach

kilonet 2010-09-09 18:53:27

Exactly! MVC != 3 tier development. MVC is the UI level only. Business logic and db access should go somewhere else.

Ryan 2010-09-09 19:26:47

ansaurus

tags:

views:

answers:

Where to write Database and Business logic in MVC?

related questions