I used to develop with ColdFusion for a while, but then left the web development arena for a while. I'm back, now, and have been hired as an intermediate (right above entry)-level web developer. My workplace is using MVC 4, but is not using the Razor view engine. The two MVC 4 books that I've purchased (as well as the huge number of tutorials and blogs out there) only discuss using Razor- which I AM using in my self-study, but I need to understand how it works when NOT using the Razor engine.
When using the ASPX view engine, how do you go about using it? Does it work like a normal ASPX page, where I place my ASP.NET controls on the page and then reference them with the code-behind in C#? Only, rather than using ASP.NET controls, I'm using HtmlHelper methods instead? Keep in mind, I'm not asking about the basic format of using <% %> instead of <#, because most of that was covered here: http://haacked.com/archive/2011/01/06/razor-syntax-quick-reference.aspx. I fail to understand how traffic will get routed to those ASPX pages through my basic HomeController (which just has a few ActionResult() methods, nothing large).
I can elaborate more, if need be.
All MVC view pages follow the same life cycle regardless of the view engine:
Routing - The request is mapped to an action method (using request data like URL, querystring, session, etc)
Controller - A controller is created for the matching action method. It's populated with all the environment, request, and session data
Action - The matching action method is called
Result - The ActionResult returned by the action method is executed. For a view result, this means: 1) The view engine locates a matching view name, 2) the matching view is instantiated with any model data returned by the action method, 3) the view is processed by the view engine.
That means a WebForms view will be executed by the MVC WebForms view engine, not by the ASP.NET WebForms system. The view engine will perform some basic parsing to add the data from your model to your view (as specified with <%%>).
Also, FYI you can even mix view engines in a single project (requires some setup).
Look at
The ethos of MVC is to get rid of code behind so the old way of drag drop onto the designer and manipulating the control from code behind has become somewhat out dated or redundant. If you are already using HTML5 helpers .. I would continue to do so.
This is purely a personal view ... but I would make a case for using Razor.
Edit: You pass the model to the view ... the model holds the data.
If you are using ASP.NET MVC then forget about code behind. As for as the view engines are concerned you can go razor or aspx way means the syntax you can use on your views is either razor or aspx. Routing will not be affected by your choice of view engine.(It will behave same whether you choose razor view engine or aspx.
And NO aspx views does not behave like normal aspx webform, no code behind no viewstate etc
Here is a good comparison of ASP.NET and ASP.NET MVC and Here is comparison of different view engines.
Related
I am working on a project that has MVC 4 and the Umbraco CMS installed. I apologise - being newbie, my question may be weird.
My question is: how do I work with types which I don't want to manage through Umbraco back office?Rather, it will be simple data coming and being stored in SQL Server.
Specifically I want to ask:
Can I create a controller in MVC and bypass Umbraco?
What controllers should be inherited from? Should they be standard MVC Controller, SurfaceController or RenderMvcController? Again, it will not be an Umbraco document type or data.
Will views be inherited from UmbracoViewPage, UmbracoTemplatePage or it can be a standard MVC view?
How will the URL of these views, controllers and actions change? In Umbraco, the URL depends on the content tree, but how it will be with non Umbraco controllers, views and actions?
Thank you so much for your precious time, guidance, sharing and help; I highly appreciate it.
You are asking a lot of different questions here.
When developing with umbraco Umbraco it's not uncommon to embed external data into your website. If we already tell you that you can use (almost) any type of dataaccess you use in plain .Net projects.
Don't loose your umbraco context
It's important when pulling in external data (e.g.) products, that you don't loose your umbraco context. You still have a breadcrumb to render, css classes for active menu's to set and so on. Your "external data" belongs probably below a node. Therefor it's a bad idea to use Standard MVC controllers.
Dirty razor
Because your views are in razor, you COULD put every extraction of external data into #{ ... } in your view. If you are not an experienced programmer, this works. Although topics about maintainablility and DRY principles are questionable :-)
RenderMvcController versus SurfaceController
When you use a RenderMvcController you basically are are creating a Controller for a specific document type. Each time umbraco is rendering a node of this document type. This controller will be invoked and the model you render is send back to the View. As you might guess, this is one of my favorite places to extract data and push it to the view.
A surface controller on the other hand is a controller for a partial view, extremely well in handeling form postbacks.
Both of these controllers can be used for the front-end of your website, not for the backend.
Inherit your views
You can do with your views what you want. But if you inherit your view from UmbracoViewPage you still have all the #Umbraco.Whatever power available in your views
Your URLS stay the same
Because you "hijack" a route using the RenderMvcController, you can just trust the umbraco backend to go to the right URL. The querystring can be used to get external data you want.
Other controllers or methods
Sometimes, if I can't use the controller above, I create an extentionMethod on the IPublishedContent. Like that I can write code like this:
foreach (var myObj in Model.Content.GetMyExternalData()) {
// do stuff
}
Of if you need to expose data (using a webApi wrapper), try the UmbracoApiController. This REST pure sang.
Data Access in umbraco
You should know that Umbraco uses petapoco as ORM. Therefor you can (and should) consider to use it too. You can reuse the database connection without any problems.
var query = new Sql().Select("*").From("myCustomTable").Where<MyModel>(x => x.Id == id);
return DatabaseContext.Database.Fetch<MyModel>(query).FirstOrDefault();
I have been using the sitecore module RazorForSitecore in earlier versions of Sitecore. After the introduction of MVC in the latest version of Sitecore this should no longer be necessary and actually the module is no longer supported. But I am confused about this part of the Sitecore MVC Developer's Reference Guide
Both ASP.NET WebForms and MVC are supported and can be mixed, although a single request must be rendered by either WebForms or MVC.
I am not interested (for now) in using MVC with routing and controllers etc.. I just want to replace my xsl-files with razor-files. One at a time. Over time. But the quote above indicates that this is not possible.
This is however what I could do with RazorForSitecore.
Am I missing something here?
Yes, you can use Razor views in the same way as XSLT, and you don't have to create models or controllers for them.
When they say WebForms and MVC can be mixed, they mean you can have some pages of your site implemented with WebForms and some with MVC, but you can't mix WebForms and MVC on the same page(1). If you want to start moving to MVC you would have to do it to a whole page at a time. So if a page is made from BrowserLayout.aspx, Content.ascx and Widget.ascx you would need to create .cshtml equivalents of each of these.
Note that you can mix MVC and XSLT on the same page so if your site uses mainly XSLTs, it might be that you can start off just converting the layout(s) to cshtml. Once you've done this, you could then convert the XSLTs one at a time.
If you don't care for routing and controllers, you can just create renderings based on the View rendering template. These automatically get the datasource item set for the rendering using #Html.Sitecore().Field("YourFieldName") or if you want to access the datasource item you could use #Html.Sitecore().CurrentItem. This technique is equivalent to using xslt renderings or ordinary sublayouts (except that with ordinary sublayouts, you need to write some code to get the datasource).
(1) unless you're loading content dynamically via ajax, or an iframe
I'm working on a new ASP.NET MVC 4 app. I'm really trying to do things the "MVC" way. In particular, I'm interested in using the Razor view engine. Please note that I come from a web forms background, so my questions may seem awkward.
I'm trying to learn if there is something equivalent to user controls in MVC? If so, what are they called? If not, what is the recommended way to creating a reusable component in MVC?
You're looking for #Html.Action and #Html.Partial.
They allow you to either render a partial view or a full blown controller action in a view. This is a common pattern of reuse in MVC land.
Occasionally you would want to make displayFor or editorFor templates, if a controller action is too heavy. The rule of thumb is if you need to do it multiple times on the page and it needs to be posted back in a form, think about doing it in a template.
Controls in asp.net cover a rather large swath which MVC granularizes a bit more.
To creating a reusable HTML component in MVC you can create a partial view in the Views/Shared folder and use #HTML.Partial("_PartialViewName") to include it in any other view or partial view. You can find out more about partial views in this article.
You could try:
Add a View Start _ViewStart.cshtml in Shared folder
Make Layout Null (if required) #{ Layout = null; }
Call this page where you want like #Html.Partial("_ViewStart")
Is it safe to say that custom controls with ASP.NET MVC are most times just partial views? And if that's the case, I'm guessing it's always up to the implementing application to dictate the behavior (through controller code) of these controls?
I have done a bit of searching, and there is almost no resources on ASP.NET MVC custom controls (either that, or I'm missing the mark with my Google skills).
Partial views are more a template for either a control or a set of controls that can be shared between views.
I'm not sure they are "Custom Controls" as such and it sounds like you are coming from an ASP viewpoint.
I think you need to first get in the mindset of MVC and out of ASP.
So for a list of items you may have a partial view that takes the list of items and a partial view that takes an actual item. So "pvCustomerList<List<customer>>" and "pvCustomer<customer>".
The pcCustomerList iterates through the list and creates a pvCustomer for each customer in the list.
Partial Views don't really have code in the controller. Instead they are passed data from the view. If there is a submit action in the partial view, then this is either handled by the controller for the view or a jQuery post back.
I hope this clears things up a little for you.
Have you checked out NerdDinner sample?
There is nice article on asp.net mvc website regarding form helpers (helper methods for views). there is explained how to create custom helper method
Link is http://www.asp.net/mvc/tutorials/creating-custom-html-helpers-cs
I've started using MVC reccently, and one thing that occurs to me is whether its possible for the concept of a Control to exist in MVC?
From what I see the framework allows the application to be nicely factored into Models, Views and Controllers, but I can't think of a nice way to take a "vertical slice" of that application and reuse it in another application.
What I mean by that is it strikes me that any UI components I build with MVC maybe not very amenable to reuse, in the same way you can reuse a Contol in ASP.NET WebForms. Ok, there are HTML Helpers but I am thinking of something more modular. Something more like the control model in WPF.
Does this dichotomy go to the heart of MVC vs WebForms, or can reusable UI components work in an MVC world?
You can still use ascx files and other features in ASP.NET Web Forms. The only missing piece in MVC is the postback model and view state oriented state management. There is no <form runat="server"> anymore and no automatically generated hidden fields. Except these, all other features can be used in ASP.NET MVC. You can still write controls that post data using a REST based mechanism and use them in your views.
So, yes, as long as your controls don't rely on a server side form for postback, you can use them exactly the same way you'd use in ASP.NET Web Forms.
I was looking for the same thing - for reusable widgets with their own data paths and found this on Steve Sanderson's Blog:
http://blog.codeville.net/2008/10/14/partial-requests-in-aspnet-mvc/
From the article:
"You’ve heard of partial views, so how about partial requests? Within any MVC request, you can set up a collection of internal partial requests, each of which can set up its own internal partial requests and so on. Each partial request renders a plain old action method in any of your plain regular controllers, and each can produce an independent widget."
This article respectfully offers a alternative to The MVC Contrib Group's Sub Controller strategy (http://www.mvccontrib.org/) which is also a solution for what you are looking for.
I guess its harder in MVC to completely encapsulate rendering and post back handling in a single control you just drop on a page. It some ways this is because ASP.NET Webforms is very abstracted from HTTP semantics and that abstraction is a framework where its possible to create reusable user controls.
ASP.NET MVC doesn't have the abstraction of webforms so you can have a control the posts to three different controllers. While it may feel like your losing easy to use controls when you move to ASP.NET MVC, I think you have a better framework for separating and reusing domain logic.
In ASP.NET MVC you have partial views which can be reused. Rob Conery has a good post on this: ASP.NET MVC: Using UserControls Usefully
I think the closest thing you'll get to an old school controls are partial views, these are effectively just shared markup that you can drop on any page. However they don't have their own controllers out of the box so the code to power the shared UI component (the partial view) would need to exist in the controller of every page that used it. There are ways to reduce the duplication of code but without implementing partial view controllers and binding I don't think there is a way around it completely.