Can someone help me understanding Model-View-Controller method to be implemented on WebForms? I am confused on couple of things:
If we have ABC.ASPX and ABC.CS files, what is view? is it only ABC.ASPX file? or combination of .ASPX + .CS file?
do we consider ABC.CS file as controller? If no, will it be a seperate class for controller?
Does database connection and data retreival go into Model or a seperate class which will be called by Model?
Can someone give a simple example for implementing Model-View-Controller in webforms?
Update
Hi guys, my question is how to implement Model-View-Controller methodology using WebForms not about ASP.NET MVC2.0. I apologise for the confusion.
Cheers
I guess I understood what you want to do: you want to implement a MVC architecture above an ASP.NET WebForms application. Fair enough.
All I can say is good luck! Me being there & done that. And how I regretted doing so... :P
Remember: ASP.NET WebForms is a huge abstraction, that tries to make the web into a statefull, event-based, windows-like environment, without any concern of decoupling whatsoever. So, trying to create an stateless, highly-decoupled and non-event-based architecture above that is, sorry to say, near insane.
Please, enlighten yourself and come to the real ASP.NET MVC world... :-)
PS: some people claim of having success implementing a MVP (Model-View-Presenter) architecture above ASP.NET WebForms. Shame on them (but you can try if you really want to)!
As others have posted there is a lot of information out there on MVC, so I'll answer your question...
If we have ABC.ASPX and ABC.CS files,
what is view? is it only ABC.ASPX
file? or combination of .ASPX + .CS
file?
It is both...however the .cs file is referenced as code behind but both make up the view.
do we consider ABC.CS file as
controller? If no, will it be a
seperate class for controller?
No, a separate class would be the controller.
Does database connection and data
retreival go into Model or a seperate
class which will be called by Model?
You could go either way. you could place this logic in the model, however you could also functionalize it out into services, which can then be called as needed by the model. IMHO the second route is the way to go, as I don't want to make my model dependent on external entities and it also makes testing the model easier, as you can separate out the services testing from the model testing.
Diagram can be seen here, which has some great imagery as reference points.
Related
At first i have to say, i wanted to ask this question on programmers but i don't have enough reputation in this stackexchange.
While i was developing a ASP.Net MVC (4) Application i came to an issue where i had to display data from a model in a view where i need a recursive function which builds the HTML for me.
I asked myself where such a funtionality should be placed in best practices. The model should not hold any logic and the controller does not communicate with the view in common. And i really don't want to put complex logic into my view.
This is a theoretically question and i hope it is ok that i asked in this forum without giving source code.
You are quite right to keep your concerns separate. What you're looking for is a ViewModel.
What is ViewModel in MVC?
I'm trying to understand a 3-layer design where MVC is (or is in) the Presentation Layer. Specifically, how would the top-down interaction concept work with respect to the Business Layer, a ViewModelBuilder, and the MVC Controller.
Should the Controller itself access the BLL?
Where does the ViewModelBuilder fit in to this?
I'm just starting to understand that the Model in MVC is actually the ViewModel rather than the Business or Persistence Model. Am I way off here?
Your confused because of the countless examples online that don't make any distinction between a simple MVC architecture and one that is serving as only the UI layer in a larger enterprise architecture. Most likely, you need the latter.
In an application of any level of real sophistication, yes, you'll want to think of your model classes as view models and then map them back to your domain model. Check out Automapper to help automate this.
Here's two really good articles that were helpful to me that I think are really well written:
http://blogs.msdn.com/b/simonince/archive/2010/01/26/view-models-in-asp-net-mvc.aspx
http://blogs.msdn.com/b/simonince/archive/2010/12/07/view-model-versus-domain-entity-validation-with-mvc.aspx
I have been doing ASP.NET MVC at university this year and only touched on some of the basic principles but absolutely loved it. Having been a PHP fan for over 6 years I planned to use something like CakePHP to continue using the MVC pattern in my work.
However I have a few questions as their are MASSIVE differences between the two frameworks:
1.) How would someone do something similar to LINQ where when ever you do your actionresult you can simple build a query and then return it to the view?
2.) Do repositories exists in Cake? I love these in ASP.NET and the ability to create custom methods for your database logic and then call them anywhere.
3.) Confusion with the model. In ASP.NET I could have a single model deal with lots of tables and then call any table or combination of tables with ease. In Cake it seems you have a model per table???
CakePHP comes with its own persistence API, whereas in ASP.NET MVC you can (and have to) use something else of your choosing.
1) There isn't an equivalent to LINQ in CakePHP, but you can still construct queries pretty easily.
2) CakePHP's models can have functions attached, and they also have something called Behaviors which are neat.
3) CakePHP's persistence system associates one model with a persistent entity (such as a table). I'm not sure I can give a better answer with out a more specific example.
I did a lot of PHP work before I moved on to .NET. While I still like ASP.NET MVC or RoR better (mostly because they are better frameworks and languages, IMHO, than PHP), the few projects I did in CakePHP were very pleasant.
I am not familiar with ASP.NET, but I can answer some of these questions.
LINQ... I am not familiar with. If
you could give a simple example, I
could explain if there is a similar
method in Cake.
The Repositories you refer to can be
Behaviors as mentioned by
#HackedByChinese. However, you may
have better results by adding
functions to the app_model.php file.
All models in the app can access any
function in the app_model.php file
which can be added to your app
directory.
Yes. CakePHP is designed with code
separation in mind. The idea behind
a single table per model allows you
build a very FAT model and still
keep it manageable. You build all of
the relationships, validation, and
other model specific code into each
model. Then when something goes
wrong with Users for example, you
know you need to look in the Users
model. This can be overridden, you
can put all of the model access into
a single model file if you want, but
it makes the code sloppy. If you are
going to do that, why use Cake? Just
put all of your model code in
Model.php, all of your controller
code in Controller.php and all of
your view code in View.php and call
it good. I think you would agree
that is not the structure for very
readable nor extensible code.
I am creating an application using asp.net MVC. By default, the model, view and controller are all in the same project, but
can I create different projects or class library projects for the model, view and controller, so I could manage them separately? Is it recommended?
You definitely can. This part of the point of MVC to allow you to have such flexibility. As far as whether it is recommended, it depends on what you are doing. It is not necessity; however I think there are definitely many scenarios where it makes sense. Although, this probably makes the most sense for the model.
I have been working with ASP.NET MVC for a couple of months now and I'm still not happy with the layout of my project's solution. I am trying to construct a mid-sized website CMS that is as portable and reusable as possible and there are some obvious problems in the design of it. I am looking for some advice regarding how I should structure my solution in consideration of separation of concerns. I've found a similar question here, but it doesn't really target some of the issues I am facing.
Right now this is how my solution is laid out:
+Project.Controllers - All Controller classes
P+roject.Controllers.Tests
+Project.Core - Utility classes including repetitive tasks and some configuration handlers (this project needs to be better fleshed out)
+Project.Core.Tests
+Project.Models - Model classes, Entity Framework context, and Repository classes
+Project.Models.Tests
+Project.Web - All Views and Content
One major thing I am currently missing is a place to stick my business logic and I feel I've been wrongly placing business logic in my repository classes as well as intermingling it in controller actions. Obviously, I'm very aware of this problem, I'm just not sure where I should placing my business logic in that solution layout. Does my solution structure need to change or can I safely keep that business logic in my Models project? Also, I really don't like that my EF Context is in the Models class, but I don't know of a way to isolate the data layer code from the Entity Classes needed in my model.
How is everyone else laying out their production ASP.NET MVC solutions?
You might want to check out the layout the S#arp architecture project uses or the onion architecture as used in the Code Camp Server MVC reference application. Both projects have had allot of effort put into them by different people to get a good sepperation of concerns in the context of asp.net MVC and domain driven design.
Personally I'm only learning MVC. My experience comes from ASP.NET WebForms but I would go with the layout proposed in the link you gave. The second answer, that is:
Models
Views
Controller
Services
Tests - one for each project.
I would take EF Context and Repositories out of Models and into a data access layer, Project.Data and put your business objects in Project.BusinessLogic (?).
This gives the benefit of putting the two assemblies (Project.Data and Project.BusinessLogic) in other apps you might build on the same domain. That means your next project has a very useful starting point.
Hope that helps,
Dan