I was thinking that you were describing a distributed architecture here - are you not? If you have a desktop and a web app doesn't that imply that? I don't want to assume too much so if I've missed the mark here let me know.
In terms of controller re-use, well put Phil :).
In terms of service layer "overhead" - I know in the case of SOAP it can be less than ideal performance, but the tradeoff is that your logic resides in one spot, brokered through your web app. There are lots of different flavors to make this response a little
quicker - RESTful services do help in this regard.
As to "why" you'd have your logic in one assembly - the alternative is to have lots of those assemblies :) and a versioning issue.
>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.
This is what I know as the Supervising Controller, whereas teh Passive View doesn't require this link.
>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.
DoX and DoY can call back into the controller and do some other stuff and finally call to render some view.
When I implement an ASP.NET I don't need to "remember" to write this. I just implement the interface defined by the controller. That's the model dictating my application logic, but I need to re-use more than a model.
Let's give another example. Suppose I have a wizard where each step asks the user for a series of operations based on the input and redirects them to different steps in the wizard. IF I implement this logic in the controller I write it once and re-use everywhere.
>I was thinking that you were describing a distributed architecture here -
>are you not? If you have a desktop and a web app doesn't that imply that?
Why would it imply that?
>In terms of service layer "overhead" - I know in the case of SOAP it can be less than ideal performance,
Forget the performance for a minute. Why would I want to add a service layer to my application? IF I have all the controller logic in one assembly, I write it once and re-use amongst different projects. I reference it in my web app and I reference it in
my PDA app and in my Winforms app. Why do I have to add a service layer?
Something like this has been done before, see <a href="http://msdn2.microsoft.com/en-us/library/ms979217.aspx">UIPAB</a>. I think it's an architectural nightmare. And by the lack of updates, I'd say there's clearly little demand for it. I'm with Phil, WinForm
and Web are distinctively different enough that reusing the same set of controllers does not make much sense to me. It will force me to invent coding patterns or design content flows that might be completely unnatural to either platform. The end result is
that maintainability and/or usability will suffer.
In my opinion, the ValidateLogin method isn't a controller method at all. It's a model method and that's where it should go.
The way I would go about doing this would be to create an ISecurityController interface, with a Login method. You could then implement the interface in both your ASP.NET MVC controller and your WinForm controller. The Login method would call ValidateLogin
method on a User model object. The big benefit to MVC is 1) separation of concerns as Phil stated before 2) reuse of models. Because of #1, the models are far removed from any specific V or C implementation, making it easier to re-use them. You could even
reuse the in non-MVC applications. Heck, slap a COM interface on them and call them from VBScript if you want. :)
public interface ISecurityController {
void Login(string username, string password) { }
}
public class HomeController : Controller, ISecurityController {
public void Login(string username, string password) {
UserModel um = new UserModel();
IsLoggedIn = um.ValidateLogin(username, password);
}
}
I'm taking inspiration for this directly from the RailsEngine:LoginEngine plugin.
# File vendor/plugins/login_engine/app/controllers/user_controller.rb, line 18 18: def login 19: return if generate_blank 20: @user = User.new(params[:user]) # what does this achieve? 21: if session[:user] = User.authenticate(params[:user][:login], params[:user][:password]) 22: session[:user].logged_in_at = Time.now 23: session[:user].save 24: flash[:notice] = 'Login successful' 25: redirect_to_stored_or_default :action => 'home' 26: else 27: @login = params[:user][:login] 28: flash.now[:warning] = 'Login unsuccessful' 29: end 30: end
I've been looking at this new MVC stuff the last two days, and I have had questions similar to frparel. From what I've read in this thread, MVC
is not (as I had thought) primarily intended to support Controller reuse. If I want to be able to put the same business logic behind different UI's (Silverlight, webpages, WFC, WinForms), I need to use a different pattern. MVC's primary value in this implmentation
seems to be the support of Test Driven Development?
It seems that in this implementation of MVC, the Controllers do two primary things. The first thing Controllers do is pass subset(s) of Model data to a View. While the View knows about the complete structure of the Model (i.e. a model of the Northwind
database) the Views don't actually get any data directly from the Model. The Controller acts as the actual Datasource for the View. A Controller may only pass a partial list of Customers from the Model to a Customer View. The second thing Controllers do
is to orchestrate the flow from one View to another. Views don't know about each other, they only know about the Controller. The Controller knows about all of the Views and transitions the user from one to the next as appropriate. Have I got this right
so far?
One thing I'm not clear on is how I'd handle (what is for me) a typical scencario. Maybe MVC isn't meant to deal with this, so maybe this isn't an issue, but it is bugging me. I might have a page/form that displays Customers, Orders, Order Details, and
Product Detail info in 4 related grids as a sort of multi-level Master-Detail display. For ease of use I want these grids all on the same form/page. Some users will only have the rights to edit Customers. Some can edit Customers but only see Orders. Some
can edit and Customers, Orders, and Order Details. Only a select few can see right down to the Product Details, and even fewer can edit those Product Details. From a user's perspective, I think a grid should only be visible if the user can view the data
in it. And there should only be an edit button available for the grids the user can edit. But doesn't this require either the View knowing all the security rules from the Model, or creating a different View for each permutation of grid view and edit-ablility,
and then having that Controller know about the Model's security rules so it can select the correct View for the particular user?
Don't think of MVC in term of controller reuse. Think of it in terms of Model reuse. Supporting TDD is just a side-effect of the separation of concerns.
For your example, I might architect things like so:
A User model which gives the controller information about what items (orders, customers, etc...) the user can/cannot see as well as whether or not they can create/update/delete the items.
The view might use a re-usable Grid component and the controller will create or show/hide the grid based on the security information it gets from the User model.
Depending on what rights the logged in user has, the controller may query one or more models. If the user can view customers and their orders, it may get a list of customers from the Customers model and a list of related orders. Say from a "Customers.GetOrdersForCustomer(int
cusomerId)" method.
One thing i see different in APS.NET MVC framwork, from my understanding of Original MVC is the responsibility of Contorller. In asp.net mvc implementation, controller is used to decouple view from the model, controller passes the viewdata to view, through
which view gets its hands on model, but then, view cannot access model on its own. In original MVC, it ws the observer pattern, that was used to decouple the model from view, and not the controller.
That is a spot on observation. The reason for that is the stateless nature of the web. By the time the view is rendered and sent to the browser, the model is no longer in memory, so it would be hard for the view to update itself from the model via the observer
pattern.
We could possibly fake it by having the object stick around in memory and using Ajax to poll the object, but that wouldn't scale well and add a lot of complexity.
Embrace statelessness I always say. [;)]
This key difference is why many call this pattern the Web MVC pattern.
Phil Haack (http://haacked.com/)
Senior Program Manager, Microsoft
robconery
Participant
852 Points
195 Posts
Re: MVC Architecture
Dec 11, 2007 08:00 PM|LINK
I was thinking that you were describing a distributed architecture here - are you not? If you have a desktop and a web app doesn't that imply that? I don't want to assume too much so if I've missed the mark here let me know.
In terms of controller re-use, well put Phil :).
In terms of service layer "overhead" - I know in the case of SOAP it can be less than ideal performance, but the tradeoff is that your logic resides in one spot, brokered through your web app. There are lots of different flavors to make this response a little quicker - RESTful services do help in this regard.
As to "why" you'd have your logic in one assembly - the alternative is to have lots of those assemblies :) and a versioning issue.
Are we still on track here?
frparel
0 Points
15 Posts
Re: MVC Architecture
Dec 11, 2007 08:01 PM|LINK
>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.
This is what I know as the Supervising Controller, whereas teh Passive View doesn't require this link.
>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.
In controller:
If (Model.CustomerAmount < 0) {
DoX;
} else {
DoY;
}
DoX and DoY can call back into the controller and do some other stuff and finally call to render some view.
When I implement an ASP.NET I don't need to "remember" to write this. I just implement the interface defined by the controller. That's the model dictating my application logic, but I need to re-use more than a model.
Let's give another example. Suppose I have a wizard where each step asks the user for a series of operations based on the input and redirects them to different steps in the wizard. IF I implement this logic in the controller I write it once and re-use everywhere.
frparel
0 Points
15 Posts
Re: MVC Architecture
Dec 11, 2007 08:05 PM|LINK
>I was thinking that you were describing a distributed architecture here -
>are you not? If you have a desktop and a web app doesn't that imply that?
Why would it imply that?
>In terms of service layer "overhead" - I know in the case of SOAP it can be less than ideal performance,
Forget the performance for a minute. Why would I want to add a service layer to my application? IF I have all the controller logic in one assembly, I write it once and re-use amongst different projects. I reference it in my web app and I reference it in my PDA app and in my Winforms app. Why do I have to add a service layer?
shinakuma
Member
378 Points
92 Posts
Re: MVC Architecture
Dec 11, 2007 08:34 PM|LINK
Something like this has been done before, see <a href="http://msdn2.microsoft.com/en-us/library/ms979217.aspx">UIPAB</a>. I think it's an architectural nightmare. And by the lack of updates, I'd say there's clearly little demand for it. I'm with Phil, WinForm and Web are distinctively different enough that reusing the same set of controllers does not make much sense to me. It will force me to invent coding patterns or design content flows that might be completely unnatural to either platform. The end result is that maintainability and/or usability will suffer.
UIPAB
Haacked
Contributor
6901 Points
412 Posts
Re: MVC Architecture
Dec 11, 2007 09:07 PM|LINK
Supervising Controller is an Model View Presenter pattern. I wouldn't confuse it with Model View Controller. It's not the same thing.
I think this post here gives a great overview of the differences.
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?
lazycoder
Member
36 Points
13 Posts
Re: MVC Architecture
Dec 11, 2007 09:56 PM|LINK
In my opinion, the ValidateLogin method isn't a controller method at all. It's a model method and that's where it should go.
The way I would go about doing this would be to create an ISecurityController interface, with a Login method. You could then implement the interface in both your ASP.NET MVC controller and your WinForm controller. The Login method would call ValidateLogin method on a User model object. The big benefit to MVC is 1) separation of concerns as Phil stated before 2) reuse of models. Because of #1, the models are far removed from any specific V or C implementation, making it easier to re-use them. You could even reuse the in non-MVC applications. Heck, slap a COM interface on them and call them from VBScript if you want. :)
public interface ISecurityController { void Login(string username, string password) { } } public class HomeController : Controller, ISecurityController { public void Login(string username, string password) { UserModel um = new UserModel(); IsLoggedIn = um.ValidateLogin(username, password); } }I'm taking inspiration for this directly from the RailsEngine:LoginEngine plugin.
cpnet
Member
54 Points
14 Posts
Re: MVC Architecture
Dec 12, 2007 03:32 PM|LINK
I've been looking at this new MVC stuff the last two days, and I have had questions similar to frparel. From what I've read in this thread, MVC is not (as I had thought) primarily intended to support Controller reuse. If I want to be able to put the same business logic behind different UI's (Silverlight, webpages, WFC, WinForms), I need to use a different pattern. MVC's primary value in this implmentation seems to be the support of Test Driven Development?
It seems that in this implementation of MVC, the Controllers do two primary things. The first thing Controllers do is pass subset(s) of Model data to a View. While the View knows about the complete structure of the Model (i.e. a model of the Northwind database) the Views don't actually get any data directly from the Model. The Controller acts as the actual Datasource for the View. A Controller may only pass a partial list of Customers from the Model to a Customer View. The second thing Controllers do is to orchestrate the flow from one View to another. Views don't know about each other, they only know about the Controller. The Controller knows about all of the Views and transitions the user from one to the next as appropriate. Have I got this right so far?
One thing I'm not clear on is how I'd handle (what is for me) a typical scencario. Maybe MVC isn't meant to deal with this, so maybe this isn't an issue, but it is bugging me. I might have a page/form that displays Customers, Orders, Order Details, and Product Detail info in 4 related grids as a sort of multi-level Master-Detail display. For ease of use I want these grids all on the same form/page. Some users will only have the rights to edit Customers. Some can edit Customers but only see Orders. Some can edit and Customers, Orders, and Order Details. Only a select few can see right down to the Product Details, and even fewer can edit those Product Details. From a user's perspective, I think a grid should only be visible if the user can view the data in it. And there should only be an edit button available for the grids the user can edit. But doesn't this require either the View knowing all the security rules from the Model, or creating a different View for each permutation of grid view and edit-ablility, and then having that Controller know about the Model's security rules so it can select the correct View for the particular user?
lazycoder
Member
36 Points
13 Posts
Re: MVC Architecture
Dec 13, 2007 03:33 PM|LINK
Don't think of MVC in term of controller reuse. Think of it in terms of Model reuse. Supporting TDD is just a side-effect of the separation of concerns.
For your example, I might architect things like so:
A User model which gives the controller information about what items (orders, customers, etc...) the user can/cannot see as well as whether or not they can create/update/delete the items.
The view might use a re-usable Grid component and the controller will create or show/hide the grid based on the security information it gets from the User model.
Depending on what rights the logged in user has, the controller may query one or more models. If the user can view customers and their orders, it may get a list of customers from the Customers model and a list of related orders. Say from a "Customers.GetOrdersForCustomer(int cusomerId)" method.
NeoAdroit
Member
102 Points
28 Posts
Re: MVC Architecture
Dec 13, 2007 04:13 PM|LINK
One thing i see different in APS.NET MVC framwork, from my understanding of Original MVC is the responsibility of Contorller. In asp.net mvc implementation, controller is used to decouple view from the model, controller passes the viewdata to view, through which view gets its hands on model, but then, view cannot access model on its own. In original MVC, it ws the observer pattern, that was used to decouple the model from view, and not the controller.
Am i missing something ?
neo.
Haacked
Contributor
6901 Points
412 Posts
Re: MVC Architecture
Dec 13, 2007 04:34 PM|LINK
That is a spot on observation. The reason for that is the stateless nature of the web. By the time the view is rendered and sent to the browser, the model is no longer in memory, so it would be hard for the view to update itself from the model via the observer pattern.
We could possibly fake it by having the object stick around in memory and using Ajax to poll the object, but that wouldn't scale well and add a lot of complexity. Embrace statelessness I always say. [;)]
This key difference is why many call this pattern the Web MVC pattern.
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?