I seem to have a problem grasping how this MVC fits in with what I understand as MVC. I know it mimics Rails and MonoRail, but here's my issue.
I've been creating controllers in ASP.NEt with the idea of not only doing seperation of concerns for testing and other purposes, but also for re-use. This means that I can implement various UI's using the same controller. For this, I would have something
like this:
public class SecurityController {
....
private IView _view;
public void ValidateLogin(string username, string password) {
if (Model.Validate(username, password)) {
_view.ShowValidated();
}
}
Then my page woulld implement IView interface. This way, any UI I create knows that as long as IView is implemented, everything is taken care of. Seems valid right?
So now eagerly awaiting ASP.NET MVC I see controller actions. How exactly does this fit in with what I've been doing up to now? Does this mean that now I have to do something like this:
public
interface IView {void DoRender();
}
public class
SecurityController {
private IView mview;public SecurityController(IView
view) {
[ControllerAction]
public void Index() {
RenderView("Index");
}
[ControllerAction]
public void About() {
RenderView("About");
}
[ControllerAction]
public void Login(string username,
string password) {
SecurityController c =
new SecurityController(this);
c.ValidateLogin(username, password);
}
public void DoRender() {
RenderView("Main");
}
}
If this is the case, then I really do see a need for [ControllerAction], otherwise I couldn't take this approach since every public method of my implemented interface would be available from the outside.
However, I guess I'm "missing something". My main purpose with MVC is to also be able to RE-USE the C, not implement one C per V.
Hmmm... I'm not sure exactly what you're trying to accomplish. Can you describe the scenario? There may be another way to do it. For example, it's easy to have multiple views post to the same controller.
Are you trying to re-use the controller in the same application?
Phil Haack (http://haacked.com/)
Senior Program Manager, Microsoft
I'm trying to re-use the controller. Forget ASP.NET for a moment. I have two interfaces to the same application. One if WinForms (let's say) and the other is ASP.NET. My purpose for using MVC is to re-use the controller.
When someone logs in using a web page, the application should validate the user and if so display the main menu. Why should i re-write this logic for WinForms/ASP.NET? I can just make sure my views implement specific interfaces and that way I leave all
the control in the hands of the controller.
Ah! I see. The architecture of a Web based MVC app (what I'd like to call "Web MVC") is a bit different than a desktop MVC app. For example, the web is stateless. We don't have any means for supporting using the ASP.NET MVC controller as is in a WinForm
app.
In that situation, I would put the validation logic in another class and reference it from your controller.
Phil Haack (http://haacked.com/)
Senior Program Manager, Microsoft
I can still abstract the logic irrelevant of state or not. So basically it's a bit twisted to be able to re-use your controller. There goes one of the greatest benefits of MVC.
What you're referring to is a service layer - business logic that is kept completely separate from implementation. ASP.NET MVC is built for web applications but that doesn't mean you can't auth against the same logic source.
To that end, I might suggest using either a RESTful interface for a web service, or SOAP to expose a SecurityService that does what you're talking about. I wouldn't wrap it with a System.Web.Mvc.Controller - this is "Web Controller" which governs web app
flow.
Before I go on - let me know if I'm headed in the right direction here.
Ok, go on :). So basically my idea of what MVC is supposed to be is wrong? Basically I have to create a C and V for every type of app I make? Problem is, I could do what I just showed previously using the normal ASP.NET WebForms approach. It had it's quirks,
but I had one controller that would be re-created on each page load and would handle the logic. The WebForm would just implement the methods dicated by the interface required by the controller.
You can still do this type of thing - either by overriding our default controller and view set to implement your code. I think the pattern you're talking about is MVP yes? I think I see what it is you want to do, but unfortunately I'm not too familiar with
MVP to help out in terms of how you'd "port this" over.
Generally speaking, however, if you want to share logic between applications (usually referred to as servicing) it's generally better to go with a servicing mechanism like SOAP/REST/Remoting - but I don't want to tell you how to create your application :).
I think your understanding of MVC is just fine - let's keep this dialog moving forward and see if we can find a solution :). Can you tell me more about what you used to do with WebForms?
To be honest, I don't know if it's MVP or not. My understanding of MVP is that there are two possiblities, the supervising controller (view talks to model for simple stuff and controller supervises for more "complex" operations) and the passive view (i.e
dumb view that doesnt' talk to the model and controller is the bridge between the two). Some call this MVC, some decide to call it MVP in two flavors. I personally don't care. I want to re-use my C. I don't want my whole benefit of MVC be about TDD. IT's about
TDD, it's about automated testing using mocks and I want it to also be about re-using controllers. In WebForms I would do pretty much the same.
I could do it now using what I described in step one, but it just seems "unnatural".
Out of curiosity though, why do you think I should expose my logic as a service? I would use a service layer if I want to have a distributed physical architecture. When I want to put all my logic into an assembly that I can use across multiple projects,
why would I go with an overhead of a service layer?
I'm not trying to pick a fight, just trying to learn from others :).
Couple of things. I don't believe the re-use of controllers is a primary benefit of controllers. When Dr. Reenskaug formulated MVC, he sought to reduce the overall complexity of a system.
The primary benefit of MVC is a separation of concerns. When you are working on the controller, you don't have to worry about the changes I'm making to the view. We can work in relative isolation. So parallelism in development is a side benefit of this separation.
Testability is another benefit, but that's a result of separation of concerns.
Now, it's very very difficult to implement a true MVC pattern on the Web in a clean manner. I suppose it is theoretically possible, but you'd be back in the same boat of trying to abstract a stateful model on top of a stateless system.
For example, in MVC the view has a direct reference to the model and the model an indirect reference to a view. This allows for scenarios like 2-way data bindng. The view can update itself when the model changes, even if it's due to some external event not
triggered by the user. You can't do that with the web because by the time you've rendered the view, the model is gone.
If you absolutely wanted to use the same ASP.NET MVC controller for the web and desktop, it is doable, but you'd have to implement an MVC framework for winforms that acts like our flavor of MVC. It would effectively
act like a stateless app.
That doesn't make much sense. In terms of re-use, the primary scenario for re-use across web and desktop apps would be the Model. That is the re-use scenario, not the controller.
I don't see this as a severe limitation. After all, the controller is all about mediating between model and view. Since web and winforms are fundamentally different architectures, it makes sense to me that you'd have different controllers. In fact, with
WinForms, I wouldn't use MVC, I'd use the Supervising Controller pattern (MVP). It's better suited to desktop apps with databinding and rich controls like WinForms.
Does that make sense? These are very good questions you are asking. I hope I've somewhat clarified things. [:)]
Phil Haack (http://haacked.com/)
Senior Program Manager, Microsoft
frparel
0 Points
15 Posts
MVC Architecture
Dec 11, 2007 06:10 AM|LINK
Hi,
I seem to have a problem grasping how this MVC fits in with what I understand as MVC. I know it mimics Rails and MonoRail, but here's my issue.
I've been creating controllers in ASP.NEt with the idea of not only doing seperation of concerns for testing and other purposes, but also for re-use. This means that I can implement various UI's using the same controller. For this, I would have something like this:
public class SecurityController {
....
private IView _view;
public void ValidateLogin(string username, string password) {
if (Model.Validate(username, password)) {
_view.ShowValidated();
}
}
Then my page woulld implement IView interface. This way, any UI I create knows that as long as IView is implemented, everything is taken care of. Seems valid right?
So now eagerly awaiting ASP.NET MVC I see controller actions. How exactly does this fit in with what I've been doing up to now? Does this mean that now I have to do something like this:
public interface IView {void DoRender();}
public class SecurityController { private IView mview;public SecurityController(IView view) {mview = view;
}
public void ValidateLogin(string username, string password) {if (username == "user" && password == "pass") {mview.DoRender();
}
}
}
public class HomeController : Controller, IView {
[ControllerAction] public void Index() { RenderView("Index");}
[ControllerAction] public void About() { RenderView("About");}
[ControllerAction] public void Login(string username, string password) { SecurityController c = new SecurityController(this);c.ValidateLogin(username, password);
}
public void DoRender() {
RenderView("Main");}
}
If this is the case, then I really do see a need for [ControllerAction], otherwise I couldn't take this approach since every public method of my implemented interface would be available from the outside.
However, I guess I'm "missing something". My main purpose with MVC is to also be able to RE-USE the C, not implement one C per V.
Haacked
Contributor
6901 Points
412 Posts
Re: MVC Architecture
Dec 11, 2007 07:55 AM|LINK
Hmmm... I'm not sure exactly what you're trying to accomplish. Can you describe the scenario? There may be another way to do it. For example, it's easy to have multiple views post to the same controller.
Are you trying to re-use the controller in the same application?
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?
frparel
0 Points
15 Posts
Re: MVC Architecture
Dec 11, 2007 08:19 AM|LINK
I'm trying to re-use the controller. Forget ASP.NET for a moment. I have two interfaces to the same application. One if WinForms (let's say) and the other is ASP.NET. My purpose for using MVC is to re-use the controller.
When someone logs in using a web page, the application should validate the user and if so display the main menu. Why should i re-write this logic for WinForms/ASP.NET? I can just make sure my views implement specific interfaces and that way I leave all the control in the hands of the controller.
Am I entirely missing the point?
Haacked
Contributor
6901 Points
412 Posts
Re: MVC Architecture
Dec 11, 2007 04:53 PM|LINK
Ah! I see. The architecture of a Web based MVC app (what I'd like to call "Web MVC") is a bit different than a desktop MVC app. For example, the web is stateless. We don't have any means for supporting using the ASP.NET MVC controller as is in a WinForm app.
In that situation, I would put the validation logic in another class and reference it from your controller.
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?
frparel
0 Points
15 Posts
Re: MVC Architecture
Dec 11, 2007 05:10 PM|LINK
I can still abstract the logic irrelevant of state or not. So basically it's a bit twisted to be able to re-use your controller. There goes one of the greatest benefits of MVC.
Thanks.
robconery
Participant
852 Points
195 Posts
Re: MVC Architecture
Dec 11, 2007 05:38 PM|LINK
What you're referring to is a service layer - business logic that is kept completely separate from implementation. ASP.NET MVC is built for web applications but that doesn't mean you can't auth against the same logic source.
To that end, I might suggest using either a RESTful interface for a web service, or SOAP to expose a SecurityService that does what you're talking about. I wouldn't wrap it with a System.Web.Mvc.Controller - this is "Web Controller" which governs web app flow.
Before I go on - let me know if I'm headed in the right direction here.
frparel
0 Points
15 Posts
Re: MVC Architecture
Dec 11, 2007 05:46 PM|LINK
robconery
Participant
852 Points
195 Posts
Re: MVC Architecture
Dec 11, 2007 05:56 PM|LINK
You can still do this type of thing - either by overriding our default controller and view set to implement your code. I think the pattern you're talking about is MVP yes? I think I see what it is you want to do, but unfortunately I'm not too familiar with MVP to help out in terms of how you'd "port this" over.
Generally speaking, however, if you want to share logic between applications (usually referred to as servicing) it's generally better to go with a servicing mechanism like SOAP/REST/Remoting - but I don't want to tell you how to create your application :).
I think your understanding of MVC is just fine - let's keep this dialog moving forward and see if we can find a solution :). Can you tell me more about what you used to do with WebForms?
frparel
0 Points
15 Posts
Re: MVC Architecture
Dec 11, 2007 06:08 PM|LINK
To be honest, I don't know if it's MVP or not. My understanding of MVP is that there are two possiblities, the supervising controller (view talks to model for simple stuff and controller supervises for more "complex" operations) and the passive view (i.e dumb view that doesnt' talk to the model and controller is the bridge between the two). Some call this MVC, some decide to call it MVP in two flavors. I personally don't care. I want to re-use my C. I don't want my whole benefit of MVC be about TDD. IT's about TDD, it's about automated testing using mocks and I want it to also be about re-using controllers. In WebForms I would do pretty much the same.
I could do it now using what I described in step one, but it just seems "unnatural".
Out of curiosity though, why do you think I should expose my logic as a service? I would use a service layer if I want to have a distributed physical architecture. When I want to put all my logic into an assembly that I can use across multiple projects, why would I go with an overhead of a service layer?
I'm not trying to pick a fight, just trying to learn from others :).
Haacked
Contributor
6901 Points
412 Posts
Re: MVC Architecture
Dec 11, 2007 07:17 PM|LINK
Couple of things. I don't believe the re-use of controllers is a primary benefit of controllers. When Dr. Reenskaug formulated MVC, he sought to reduce the overall complexity of a system.
The primary benefit of MVC is a separation of concerns. When you are working on the controller, you don't have to worry about the changes I'm making to the view. We can work in relative isolation. So parallelism in development is a side benefit of this separation.
Testability is another benefit, but that's a result of separation of concerns.
Now, it's very very difficult to implement a true MVC pattern on the Web in a clean manner. I suppose it is theoretically possible, but you'd be back in the same boat of trying to abstract a stateful model on top of a stateless system.
For example, in MVC the view has a direct reference to the model and the model an indirect reference to a view. This allows for scenarios like 2-way data bindng. The view can update itself when the model changes, even if it's due to some external event not triggered by the user. You can't do that with the web because by the time you've rendered the view, the model is gone.
If you absolutely wanted to use the same ASP.NET MVC controller for the web and desktop, it is doable, but you'd have to implement an MVC framework for winforms that acts like our flavor of MVC. It would effectively act like a stateless app.
That doesn't make much sense. In terms of re-use, the primary scenario for re-use across web and desktop apps would be the Model. That is the re-use scenario, not the controller.
I don't see this as a severe limitation. After all, the controller is all about mediating between model and view. Since web and winforms are fundamentally different architectures, it makes sense to me that you'd have different controllers. In fact, with WinForms, I wouldn't use MVC, I'd use the Supervising Controller pattern (MVP). It's better suited to desktop apps with databinding and rich controls like WinForms.
Does that make sense? These are very good questions you are asking. I hope I've somewhat clarified things. [:)]
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?