I work on a big Active Directory Project where I need to remake the whole intranet application using ASP.NET MVC. I was wandering if Razor was a necessity here ? Especially for forms, I'm having a hard time with Razor forms (what a noob).
I have read that Razor is essential for scalable applications, which I guess is the case here, but if I could dodge this ugly stuff, that would be great.
In the end, do I need to use it for everything?
I have seen examples on the net that use classic HTML forms, and Razor for conditions and such. I don't mind using it for conditions, I just can't figure out how to render my forms with it. Is it ok to use normal html forms, or will it create some scalability issues in the future when I have 1 billion documents? :)
Thanks for your help, hope this isn't too redundant, I've seen this subject all over the place.
You don't need to use the Razor Html Helpers to generate form/input tags (you can use standard HTML markup), but you'll miss out on some of the benefits (specifically integration with a viewmodel to pre-populate fields, validation, etc). You'll also need to make sure your input names match up properly when capturing the FORM POST on the submission side.
It's up to you want you want to go with.
This can help you decide.View Engine Comparison
Related
Just to prefix this question, I've decided to take a look at moving our works old legacy systems (40+ programs from vb6, vba, vb.net to c#.net) into two separate systems using the same DAL (barcoding terminals and one web based system) as I spend most my day fixing crummy or non existant business logic in 15 year old vba programs. I've recently built an entity framework model complete with fluent validation and couldn't be happier with it after using it for a bit.
The small team is familiar with webforms (but not very) but the last few days I've explored MVC Razor. I was loving MVC Framework until I tried to start trying to add more functions onto the same page and then it seemed arbitrarily hard to replicate our a recent system I put in a webform. Before, I would eager load a customer and all it's child entities and then bind that to single page for the customer so they could access everything (which is what they wanted), it works okay and isn't slow. From this single page I could edit all their account details/contacts/emails/phones/jobs.
All the examples I've done and seen in MVC handle a single update, a single edit etc but surely you can't separate out every single action into a new view/page? I can pass a rich model through to the view in MVC, but then its a pain trying to update all the different child entities.
This is probably the exact design that MVC wasn't designed for maybe, which is okay, I'm willing to adapt it if MVC will be a better platform going forward, but how are you meant to handle adding this complexity in? Some methods I've seen:
Lots of partial views? passing child info to them (or the id and lazy loading it)?
I've seen methods that wrap multiple <forms> around everything and handle actions that way.
Separate pretty much every task out
If the solution is more lightweight and easier to maintain I'll go research whatever I need to I just wanted at an earlier stage to see if I'm wasting my time. Any pointers to the correct questions I should be asking would be greatly appreciated.
ASP.NET MVC is neither more or less better equipped to deal with complex pages than any other technology out there.
Certainly, MVC requires more low-level work than a Web Forms app, with no direct binding support, but in most cases this is a good thing and provides much more flexibility in how your page is rendered.
One of the whole ideas of MVC is to give you more control over things, but that control leads to requiring more knowledge and more effort on your part in most non-trivial cases. MVC provides a number of tooling functions to speed up trivial work (like creating standard table based CRUD) but when you have complex models, you will have to do much of the work yourself.
This is not that MVC is "ill suited" for it, but just that control and flexibility has a trade off with more responsibility on your part.
In your case, you simply create a view model with all the fields you want. Then, you create your form to edit those fields. In your controller, you will need to unflatten that view model and create or update the necessary records in the database. It's not difficult, but it's more work than WebForms databinding.
You could look into more advanced tools (commercial) for MVC, such as Telerik's tools, which have developed more of a databinding like interface, but MVC is not a drag-n-drop technology, and requires you to hook things up and write the various logic for what is done.
If you need drag-n-drop, databound functionality, then no.. MVC is not the correct technology. But then WebForms requires you to accept many compromises as well, and ties your hands in many ways.
You could use partial views, however I seldom use them. I prefer to instead use Editor/DisplayTemplates as these take care of naming your form fields correctly, even for collections and complex objects. PartialViews tend to have lots of gotchas if you aren't careful. I pretty much only use them as fancy includes, or when using Ajax.
I'm not sure what you meay by "wrap multiple <forms> around everything`. You cannot nest forms in HTML, it's not legal. If you mean place a form around each row of a table, that isn't valid html either in most cases (it's not legal to put a form in a between the table and the tr).
It would help if you had a specific problem that you could ask about, vague objections don't help us solve your issue.
You can accomplish anything in MVC that you can in WebForms. The difference is MVC will usually require you to write more code as it doesn't really offer you any "controls" to drop on your page.
In WebForms, it's easy to create a master/detail view with a GridView, FormView and then wrap everything in an UpdatePanel for automagical AJAX support.
In MVC, while you do have helpers like the WebGrid and AjaxHelpers extension methods, creating views and/or pages requires more understanding of how things work to get the desired functionality. When I start a new MVC project, here's what I include:
Backbone.js - client-side "ORM" that performs CRUD operations
against RESTful* APIs
Knockout.js - client-side view models and
real-time data-binding for your views
Knockback.js - wraps
Backbone models in Knockout view models
Using these three frameworks, you can quickly create powerful single-page apps using MVC and WebAPI.
Im looking to make the editor templates in my MVC application use HTML5 input types. The framework seems to get about 80% of the way there but there are a couple of things I can't seem to make happen (step values on numerics, placeholders, URL inputs, etc).
I'm sure that quite a bit of this is just me not knowing where to look, but
Is there a definitive list of what attributes I can use on View Models to provide the metadata used to generate the html?
Does anyone know of a project / nuget package that helps with this? I'm not opposed to writing something, but would rather use something that's already been tried and tested. Dean Hume's ASP.net MVC HTML5 Helpers Toolkit is close, but I'd like to put as much information in the attributes as possible and let the runtime do the work via Html.EditorFor (just a personal preference).
Thanks,
Joe
Check this out : http://weblogs.asp.net/rashid/archive/2010/10/21/integrate-html5-form-in-asp-net-mvc.aspx
See if it can help you get started.
I have a CMS website written in aspx 2.0 that allows users to build up pages by dropping controls on a page and setting properties (reflection on the server side) and events (client side js). The render engine knows what property to call on each control to find out what to save into the database. I went through all the pitfalls of control re-hydration and lack of proper ids on the controls and really struggled to make the solution SEO friendly which currently is partial at best. Also suffer from viewstate getting huge so I have started to look at MVC as a better way forwards for the next version. The final design of the page is only set when the user decides to promote it live, and may make many changes per day.
A typical page may have many textbox controls, radio button groups, checkbox groups, dropdownlists and images. Also we have a few of our own controls that we reflect at runtime into the solution.
From my initial research into MVC, this looks to have been written to avoid these types of issues and not try to hide the html which looks very promising as well as giving final markup that is much more cross browser friendly.
Now the question - since the requirements are to generate dynamic pages with dynamic html controls, is this a step too far for MVC and I should stick with ASPX, or is there a way to generate the dynamic content which would be suitable for a non technical person to be able to do?
Really appreciate any guidance before I jump in with both feet :)
Thanks
Mark
I'm assuming by aspx 2.0 you mean WebForms? It's really not a question of if MVC is capable of doing what you need - it is capable, and in
my opinion it's more capable. However There are some major differences between WebForms and MVC check out this post for more on that topic: MVC versus WebForms.
I hope this helps. Without more information on exactly what you're trying to accomplish, there's not much more I can say. Consider asking more specific questions with some code examples.
Some of the main advantages of MVC: Clean HTML, No ViewState written on the page, easier to support html5 and thus SEO as well.
For me, since I used MVC 3 years ago I don't even want to touch WebForms thesedays.
Btw, if you want CMS + MVC, why not use Orchard rather than building yourself?
http://paulmason.biz/?p=118
i recently was working on an ASP.NET MVC site that basically serves static html and uses ajax gets to return data to the page when inputs are changed. there is actually no posting or getting from an html input tag on the pages at all. (it is a specific style of site that is not used by the general public, so having compatibility problems for people without javascript is not an issue)
after designing the site, i realised that i hadn't even included any form tags. as the site does not use any direct posts or gets, and apart from it being just good html design, i wondered, in my particular situation, if there was any point to having any form tags on the page?
As ASP.NET MVC tries to differ from Web Forms, to introduce a new approach in designing web applications. They do not require forms. In fact i think it's better not to be used for navigation, submitting data, etc. Otherwise, there is no use of the MVC pattern if you still do it "the good old ASP.NET" way.
Of course ... I'm sure there are good reason forms to be used in proper places, but not as a general concept in your design.
You can read here: http://msdn.microsoft.com/en-us/magazine/cc337884.aspx how MVC was introduced in the beginning. "ASP.NET MVC - Building Web Apps without Web Forms" by Chris Tavares
Retaining a form is useful if you need your application to degrade gracefully if JavaScript is disabled or the likes. Also, jQuery and Prototype have nice Ajax helpers for serializing inputs using a form, which is really nice when you have multiple sets of data that could be submitted to different ajax endpoints from one page.
So I guess the answer to my question is no.
I am sorry for possible misleading about the title, but I have no idea for a proper title.
Feel free to edit.
Anyway, I am using ASP.NET Web Forms, and maybe this isn't how web forms is intended to be used, but I like to construct and populate HTML elements manually. It gives me more control.
I don't use DataBinding and that kind of stuff. I use SqlConnection, SqlCommand and SqlDataReader, set SQL string etc. and read the data from the DataReader.
Old school if you like. :)
I do create WebControls so that I don't have to copy-paste every time I need some control, but mostly, I need WebControls to render as HTML so I can append that HTML into some other function that renders the final output with the control inside.
I know I can render a control with control.RenderControl(writer), but this can only be done in (pre)Render or RenderContents overrides.
For example.
I have a dal.cs file where is stored all static functions and voids that communicate with the database.
Functions mostly return string so that it can be appended into some other function to render the final result.
The reason I am doing like this is that I want to separate the coding from the HTML as much as I can so that I don't do <% while (dataReader.Read()) %> in HTML and display the data. I moved this into a CodeBehind.
I also use this functions to render in the HttpHandler for AJAX response.
That works perfectly, but when I want to add a control (ASP.NET Server control (.cs extension, not .ascx)) I don't know how to do that, so I see my self writing the same control as function that returns string or another function inside that control that returns string and replaces a job that would RenderContents do, so that I can call that function when I need control to be appended into a another string.
I know this may not be a very good practice.
As I see all the tutorials/videos about the ASP.NET MVC, I think it suite my needs as with the MVC you have to construct everything (or most of it) by your self, which I am already doing right now with web forms.
After this long intro, I want to ask how can I build my controls so I can use them as I mentioned (return string) or I have to forget about server controls and build the controls as functions and used them that way?
Is that even possible with ASP.NET Server Controls (.cs extension) or am I right when I said that I am not using it right.
To be clear, I am talking about how to properly use a web forms, but to avoid data binders because I want to construct everything by my self (render HTML in Code Behind).
Someone might think that I am appending strings like "some " + "string", which I am not. I am using StringBuilder for that so there's no slowness.
Every opinion is welcome.
You need to stop thinking in terms of "controls" and webforms. MVC is a completely different way of constructing applications.
I also hate the automatic renderers in WebForms, they produce horrible html that never makes any sense. However, you dont want to be writing your html in your codebehind and passing it around as strings, thats just nasty. Your presentation code is mixed in with your logic, AND youre writing HTML in c# strings!!!
So, MVC... Instead of "widgets" that do interacty things with codebehinds and postbacks, yours view ONLY display data and contain forms to allow you to post to the controllers.
Because of this, you can strongly type your views to a Type, and then access the data you pass to it from a controller via the Model property. The equivalent to UserControls are Partial Views (ViewUserControl) which can be used to modularise your rendering code for types. For example, you might make an Address partial to which you pass your Person's Address property every time you need it rendered. This way you aren't repeating html all over the place.
P.S. A single file for all your DAL?
I hope I never ever have to work on an app you wrote in this manner. If your application is string-heavy then something is wrong.
Agree with #sliderhouserules, the way you are using MVC framework is awful. You must forgot all your "old school" techniques.
You should never use SqlCommands, SqlReaders, etc. in the code of the pages. You should pass to the view only a model (e.g. View(bar)) and it will be better if you avoid usage of
ViewData["some magic string"] = bar
Every time when you will use "old school" technique 2 mans and 2 cats will be killed :).
Also it's better to use some ORM (Object-Relational Mapper) like Linq2sql, NHibernate, SubSonic, etc.
If you need in samples of good application design please look at SharpArchitecture. It has a very good architecture and implementation and may help a lot. It has one sample (with Northwind db) and one more sample will be added soon.
Also look at CodeCampServer. It has very good architecture too.
It's better to look at the code of these projects instead of looking videos because existing videos can't demonstrate good sample of architecture, just a simple usage of functionality.
About server controls, you may use them if they can be used without 'runat="server"', like PlaceHolder. And you may create them too, but you shouldn't load any data in them directly. If you don't want to copy-paste html you should review your code and you should refactor it. Every duplicated code should be moved to MasterPages of UserControls (ascx ones).
And once more, please spend some time to look at these samples. You'll save your nerves and time in the future when you'll need to update the app or fix something. At the first look they can be hard to understand but this is only at the first look.
Hope this helps.
#lopkiju, I think that the MVC pattern would serve you much better than your current WebForms solution if you want that much control over the output HTML.
You can use Web Forms this way as you already do, but it is not designed to be used this way, so it will be a pain.
More detail
In my opinion, read some articles about the Separation of Concerns (also known as SoC) principle. If you apply it correctly, it can save you many-many headaches when you'll debug your app, and also for those people who you work with (eg. those who may have to read or modify your source code).
My other tip for you is this:
You are right that you shouldn't do things like <% while (dataReader.Read()) %> in your View code. But perhaps there are better ways to make it more elegant than your current way.
I think you should consider using some sort of ORM for these purposes. (LINQ to SQL, or even NHibernate.) If you get it, it will be much simpler. So much that you may not want to use DataReaders directly again. :-)
What I recommend for you
Simply, read the NerdDinner tutorial, and build the samle app by yourself step-by-step.
After that, try to build a similar app that serves a different purpose by yourself while applying the same rules and design that you applied to the tutorial.
I'm pretty sure you have the expertise to do it, and after actually doing something with it, you can pretty much get the feel of it.
The tutorial also explains and includes the principles I mentioned above, which will be very much use to you.
If you want the ASP.NET MVC path, you can set up controls as ASCX and they will simply be tags filled by the controller. It may not be old school enough for you, however.
You can create your full UI in code behind, if you so desire. This can include creating the HTML in routines.
But, I would recommend, if you are sticking with ASP.NET, reconsidering the bind model over the DataReader.Read() and output + loop. It is not only old style, it is highly inefficient and hard to maintain.
ASP.NET MVC does create a much looser ASPX, as it is just a view. And there is a much greater separation of code and UI. But it will not fit with the old school model either.
Have you considered using micro-templates? Dave Ward has a good example of of a client side data repeater that is uses micro-templates for layout after making a call to a page method. This sounds like this is more in the spirit of what you are trying to accomplish and can still be integrated nicely with WebForms.
The side effect will be that you will not rely on passing around HTML and can isolate your presentation from your logic.