I think the combination of the Model and using LINQ for data access, blurs the line in a major way towards separating the business logic from the data access. It's not that this is always a bad thing but I can imagine scenarios where it would be helpful to
maintain that separation. Sure, ASP.NET MVC helps provide a separation of concerns, but the logical and even physical views of these concerns live beside each other in a single project. There is no method that I can see that creates any form of separation
between my business layer and my data layer, which appears to have been lumped together in a model using this framework. I guess at the very least you can separate your controllers, models, and views in different projects/DLLs. That at least allows me to reuse
my models and controllers with another view, such as a web service, etc. Does anyone have any suggestions on how to achieve that separation using the ASP.NET MVC framework?
Well, you pretty much hit on the answer yourself. Yes, there is a model folder that should hold your BLL/DAL tiers, but that doesn't stop you from separating them. You could just create a BLL namespace and a DAL namespace (I wouldn't do it that way,
but that's an option). And yes, I it's a good idea to put your business and data access layers into a separate project for reuse across multiple platforms.
That's where I think the MVC concept's strengths become apparent. It really opens your eyes to separation, at least compared to web forms asp.net.
That it certainly does do. I'm really quite excited to see the MVC framework. I loved it in Rails and am so happy to see it in ASP.NET.
I'm trying to build out a solution with multiple projects, one for each of the layers (Web, Test, Controller, Model, and Data). I'm unable to make a reference to System.Web.Extensions (3.6) from the GAC and it's not showing up in my .NET tab on the "Add Reference"
screen. I can browse to it in the GAC but am unable to select it to make a reference. What am I doing wrong here?
Well, typically (and everyone, correct me if I'm wrong) you'd want to have your Web project contain the
controllers and views while your business logic and data access were in a separate project. You shouldn't need to reference the System.Web.Extensions from the business/data project. I'm not sure how to word this, but the business/data project
should be able to build and perform its job alone. Your Web project would need the reference to System.Web.Extensions (and your business/data project), the extensions reference is done automatically when you create a new MVC application in Visual Studio.
Did I answer your question(s)? Phweew...
Marked as answer by CompiledMonkey on Jan 03, 2008 01:01 PM
As Chad's pointed out, I don't see any reason why you would want to separate out your controller and views. The controller is pretty focused on working with the views you have in your MVC application. It's quite hard to re-use the controllers for other setups,
and more for web service.
Separate out our model (which is your application logic and it includes your data access and business logic) into separate projects. Those are the components that you can and should re-use in different application fronts.
CompiledMonk...
Participant
816 Points
182 Posts
Do you find that the MVC framework removes the traditional BLL/DAL?
Jan 03, 2008 02:07 AM|LINK
http://weblogs.asp.net/cstewart/
ChadThiele
Participant
983 Points
274 Posts
Re: Do you find that the MVC framework removes the traditional BLL/DAL?
Jan 03, 2008 02:28 AM|LINK
Well, you pretty much hit on the answer yourself. Yes, there is a model folder that should hold your BLL/DAL tiers, but that doesn't stop you from separating them. You could just create a BLL namespace and a DAL namespace (I wouldn't do it that way, but that's an option). And yes, I it's a good idea to put your business and data access layers into a separate project for reuse across multiple platforms.
That's where I think the MVC concept's strengths become apparent. It really opens your eyes to separation, at least compared to web forms asp.net.
CompiledMonk...
Participant
816 Points
182 Posts
Re: Do you find that the MVC framework removes the traditional BLL/DAL?
Jan 03, 2008 02:44 AM|LINK
I'm trying to build out a solution with multiple projects, one for each of the layers (Web, Test, Controller, Model, and Data). I'm unable to make a reference to System.Web.Extensions (3.6) from the GAC and it's not showing up in my .NET tab on the "Add Reference" screen. I can browse to it in the GAC but am unable to select it to make a reference. What am I doing wrong here?
http://weblogs.asp.net/cstewart/
ChadThiele
Participant
983 Points
274 Posts
Re: Do you find that the MVC framework removes the traditional BLL/DAL?
Jan 03, 2008 03:00 AM|LINK
Well, typically (and everyone, correct me if I'm wrong) you'd want to have your Web project contain the controllers and views while your business logic and data access were in a separate project. You shouldn't need to reference the System.Web.Extensions from the business/data project. I'm not sure how to word this, but the business/data project should be able to build and perform its job alone. Your Web project would need the reference to System.Web.Extensions (and your business/data project), the extensions reference is done automatically when you create a new MVC application in Visual Studio.
CompiledMonk...
Participant
816 Points
182 Posts
Re: Do you find that the MVC framework removes the traditional BLL/DAL?
Jan 03, 2008 03:20 AM|LINK
http://weblogs.asp.net/cstewart/
ChadThiele
Participant
983 Points
274 Posts
Re: Do you find that the MVC framework removes the traditional BLL/DAL?
Jan 03, 2008 03:33 AM|LINK
Glad I could help.
hhariri
Member
176 Points
70 Posts
Re: Do you find that the MVC framework removes the traditional BLL/DAL?
Jan 03, 2008 05:59 AM|LINK
As Chad's pointed out, I don't see any reason why you would want to separate out your controller and views. The controller is pretty focused on working with the views you have in your MVC application. It's quite hard to re-use the controllers for other setups, and more for web service.
Separate out our model (which is your application logic and it includes your data access and business logic) into separate projects. Those are the components that you can and should re-use in different application fronts.
http://hadihariri.com
http://twitter.com/hhariri