8 Dec 2009 8:10 PM #141
Thanks for the appreciation, it means a lot to me.
To answer your question it is important to understand, that we are not comparing two different implementations of server-side stack for Ext.Direct, but what each server-side technology has to offer and how much of that you will actually benefit. When you look at it from this perspective, the answer is obvious. To show what I mean let's see how ASP.NET Web Forms and ASP.NET MVC are different. Here we go: Compatibility of ASP.NET Web Forms and ASP.NET MVC
As you can see, the strengths of ASP.NET Web Forms model are all about pages (i.e. Web Forms), so if you chose Ext JS for your client-side, you are not taking advantage of any of these strengths and hence pretty much defeating the whole purpose of this model.
ASP.NET MVC model, however, has strengths that you will absolutely take advantage of. Even the Views when you need to return plain HTML to show in a Ext.Panel. ASP.NET MVC offers all you will ever need for Ext JS application. And because it is built on the ASP.NET framework, it includes features such as membership, authentication, roles, and configuration. In addition to that ASP.NET has unique features such as Action Filters and Model Binders, that are also extremely useful.
To better feel the difference between the two models I suggest you to spend some time and play around with ASP.NET MVC. You will quickly realize that it offers the power of ASP.NET Framework without the complexity and overhead of ASP.NET Web Forms. When you write your client-side in Ext JS, it is all you need. MVC simply fits the web a lot better.
I hope I answered you question. Good luck!
9 Dec 2009 7:47 AM #142
Thanks for the detailed and quick reply Eugene,
I can totally see the benefit of MVC pattern vs Web forms, without question, as the tool of choice for your server-side needs when ExtJS is on the client. What is less obvious to me though at this stage of the game, is what MVC has to offer over the .Net Router implementation, especially given the fact that you would barely even use the "V" of MVC. I mean they both seem to implement routers for RPC calls and they both generate API stubs for the client side...and since they both are implemented on top of Direct, you are on equal footing there as well.
So, I guess what you're saying is that yes, they both can get the job done, so given the two flavors, why not use the one that was born from the ASP.NET framework, which has other cool goodies that you mentioned (Action filters, Model Binders, etc). And it seems that you have done your research on the code, so as long as there is not the usual MS code bloat that has been running rampant over there for the last couple of years, I would agree with that choice.
Any more you can offer as to why use .Net MVC over the .Net Router? Or does the above pretty much cover it?
Thanks again...onward with my MVC research
9 Dec 2009 5:29 PM #143
I think what you said pretty much covers it. I see no point in creating a Web Forms app if I am not going to use any of its features. And those goodies that MVC offers are really useful.
16 Dec 2009 6:40 AM #144
Pretty deep into my MVC review, and although an MVC will result in a bit more complexity to the overall app design, it really seems to be the way to go with where the .Net framework is headed, especially with the Entity Framework (EF) stuff. I even got a virtual machine going with MVC 2.0 and VS 2010 beta, but after working with it a little while, it's still a little buggy so backed it down to VS 2008 and MVC 1.0 for now. Was wanting to take advantage of the newer EF 4.0 changes, but as long as I implement interfaces and concrete classes, I should be able to move to that pretty easily.
I am now review your DirectController, very cool stuff. I have two quick questions:
1 - Why is there the need to manipulate the Request variable for the incoming path for the router? In other words, why the need for the following code in the Default.aspx page:
// Change the current path so that the Routing handler can correctly interpret // the request, then restore the original path so that the OutputCache module // can correctly process the response (if caching is enabled). string originalPath = Request.Path; HttpContext.Current.RewritePath(Request.ApplicationPath, false); IHttpHandler httpHandler = new MvcHttpHandler(); httpHandler.ProcessRequest(HttpContext.Current); HttpContext.Current.RewritePath(originalPath, false);
Thanks for your help!
18 Dec 2009 7:27 AM #145
Also, I am curious how you structure your MVC application project(s) if you want to separate out your business logic (service layer), models, and controllers from the the UI.
Love to hear what you are doing here...thanks!
26 Dec 2009 9:05 AM #146
Hi Bucs. Sorry, I couldn't reply sooner.
That piece of code in your second last post is part of MVC project template and I'm not 100% sure what it is for. ASP.NET MVC forums would be a better place to ask.
Regarding combo boxes there's 3 ways to deal with them:
One of them is rely on batching, as you mentioned. First you call load() method of the combo's store, and then call a method that loads the form. The two requests will be batched into one HTTP call and will be processed in the same order you called them upon return to the client.
Second option is you make one call to the server and return an object that contains the records for the combo as well as the data to load the form. Then you pass the combo records to the loadData() method of the combo box, and form data to the setValues() method of the BasicForm.
Third option is to use the override of setValue() method from this post.
26 Dec 2009 9:13 AM #147
We keep the controllers in the web project. All our business logic is in a separate middle-tier project in the solution. The controller actions in the web project are extremely simple, they merely call one or more middle-tier methods and return the results of those methods to the client. The model is also in a separate project.
11 Jan 2010 3:40 PM #148
DirectStore CRUD function signatures
DirectStore CRUD function signatures
I have been digging around the forums for quite a while and have not been able to find out what the basic function signatures (assuming no additional parameters) for the create, read, update and destroy methods should be.
Any assistance would be appreciated.
As is typical, a couple of hours (and a log of stepping through code) I was able to identify my issue. What I was experiencing was that the CRU methods could not have parameters. As it ends up, I needed to set "encode: false" for the JasonWriter object that was associated with the store. Now, for parameters, I receive the baseParams and a rows object that contain the modified rows. Currently, I am mapping this to a JObject as the only parameter to the CRU methods (this will probably change).
Last edited by bwaters; 12 Jan 2010 at 8:41 AM. Reason: Problem resolved...
13 Jan 2010 2:55 AM #149
Bucs, what issues did you find with MVC 2? I am having some roblems as well. There appears to be something wrong with the new framework and the execution of the DirectHttpModule.
14 Jan 2010 5:28 AM #150
MVC 2 Issue
MVC 2 Issue
The issue is caused by MvcHandler implementing IHttpAsyncHandler now. There is a new method in the MvcHandler called ProcessRequestInit that checks to see if the request maps to a valid controller. This used to exist in ProcessRequest which is overridden in the DirectMvcHandler. This mucks things up. I have an ugly work-around in place for now. I'd love to hear if anyone has a nice fix for this.