I am currently evaluating ASP.NET MVC as a possible technology for a web project. As I am a beginner to ASP.NET MVC I need a bit of advice.
We currently have an ASP.NET system that renders grids from data that is retrieved from a database using OLE DB and data tables. The data is rendered on a web page using a grid view that uses the columns from the database. The system is built in a generic way and driven from the database so that we do not have to write a custom page to display and render each table in the database. We effectively have one ASP.NET page that is used to render and edit different tables in the database.
We are looking at rewriting the system using ASP.NET MVC. Is it possible to have generic models, controllers and viewers in ASP.NET MVC that use dictionaries or lists instead of having separate classes for each table in a database?
On the controller side I have seen the following article to convert a data table to an IEnumerable:
Convert DataTable to IEnumerable
However, I am not sure whether the same can be achieved on the model and viewer side.
Is the whole idea of generic models, controllers and views perhaps contrary to the idea of ASP.NET MVC?
Regards
Lucas
First, you don't need custom models for views or controllers if you know you will be using something generic.
Second, you can write editor/display templates that can work on generic data and you can use them in your views.
We are looking at rewriting the system using ASP.NET MVC. Is it possible to have generic models, controllers and viewers in ASP.NET MVC that use dictionaries or lists instead of having separate classes for each table in a database
Generic solutions are very often a excellent recipe for maintenance nightmare. They work well until you have to extend the application. In my experience you do not switch from the generic solution when you want something extra, but do a small workaround. Next time you'll add another small workaround. And after a year you do not want to touch that application again.
If that's not the case for you, congratulations! You can just use a DataTable as your model in the view.
Related
I would need to create dynamic online forms, e.g. using ASP.NET MVC and Razor as view engine. So you would be able to select a form template, populate it, add new fields, etc.
Are there any references/guides I could follow? I tried searching but couldn't really find any. Creating a main template view with controller, and partial pages with sub-controllers could be one way. This way validation and transformations would be quite well encapsulated.
There is a similar question here on StackOverflow:
Dynamically Produce Razor Views at Runtime?
Also, among the ten tricks for razor views, the two last tips are about building views and eegerly generating code from razor:
http://odetocode.com/blogs/scott/archive/2013/01/09/ten-tricks-for-razor-views.aspx
Maybe those two links can help you getting started at the least
I wonder if it's possible to test ASP.net MVC views without pre-compiling the views. I found many example on the internet but none of them could test the view. They could only test the model of the view.
Update
The views are xml template. I have some logic in controller and I want that to get views from the controller.
You can render Razor views standalone using RazorEngine or one of the solutions here. This will give you HTML which you will have to parse.
However, the reason you haven't found any examples of testing views is that few people do it. Views are declarative; they don't have logic. It takes time and effort to develop a test strategy for views. A better strategy might be to move any logic contained in your view into the models where it can be tested easily.
Guys i am looking for some awesome tips for developing a page which allows users to search for stuff from the db with the view restricted to only certain columns and the data grouped by and sorted by certain columns..
the source in this case is pretty easy to figure out which is a class which retrieves the search results...kapish..
the view in this case is giving me nightmares as i do not want to write that disgusting piece of code which many asp guys are seemingly used to...overriding row created and data bound of gridview etc etc.... i am thinking of simply rendering a html table itself with the necessary preprocessing applied at the datatable level(group by, sortby etc etc on the in memory object retrieved from the paged results)
i need to know if my thought process so far is right or is there a cleaner way of doing the whole thing in asp.net/asp.net mvc etc etc
Congratulations for not wanting to write "disgusting piece of code"... I spent a few years doing just that and the whole overriding row created / bound / etc. thing is a nightmare.
Your source is a class - great. My preferred method would be to go down the jQuery route, use the jqGrid and write an MVC controller that uses your custom class. Or you could dynamically generate your own HTML table but if you have a lot of data I would save yourself the time and explore jqGrid instead. It doesn't have to be MVC - you could embed it into a standard asp.net website, it's just that the MVC approach makes life easier if you have to expand your application to do more things.
I'm just getting started with ASP.NET MVC and am going through the NerdDinner tutorial. As I'm going through I'm trying to apply what I see with how I will develop my site. I have experience with WinForms and much of what I'm wanting to do is display large amounts of data contained in a database.
I have used DataGridView along with DataSets and DataTable accessing SQLite databases. Going through the NerdDinner tut I see mainly access to SQL Server through Linq to SQL and generating HTML tables rather than using ASP.NET Web UI Components such as GridView.
I like most of the functions and look that the Web UI Components can bring, but I'm not sure if they are necessary. How do you all decide when displaying lots of data from databases what display components to use?
By experience with MVC and ASP .Net Control, your better not user control in a ASP Web form application.
The point is that they work with view state that is against the pattern of MVC.
In the case of your DataGridView what I would do is to loop through the list with a foreach and output a table row.
Phil Haack has a good post of using the jQuery Grid plugin with MVC to create a more "out of the box" grid solution like what you would be used to with the ASP.NET controls you mention.
MvcContrib has a lot of great things to aid with ASP.NET MVC development. In this case the Grid would help you a lot. I've used it in the past and found it to be pretty slick.
If you're using jQuery as well, this article talks about integrating it with the jQuery datable--makes paging and sorting essentially no-effort/painless.
I am not starting an argumentative discussion here and this post is not about career development, but from the commercial point of view:
If a company was using ASP.Net MVC as a main methodology to build their web sites and application.
However, ASP.Net MVC takes more time to show a functional application than ASP.Net Web Forms, for example, building domain models would take some time which obviously can't be represented on a UI at that current stage.
My question is, if a client wants to see a functional demo application (just a proof of concept) so he knows that the company he is dealing with is professional and capable of doing that. Would it be better to do that demo in ASP.Net Web Forms only to show the client, and then work on the real application using ASP.Net MVC? If not, what are the (quick) alternatives?, I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
WebForms being faster than MVC is a myth:
You are not required to have a domain model, just something that represents your database tables. This is the same in WebForms unless you are using SqlDataSource's.
The code in your !IsPostBack or btnSubmit_OnSubmit is almost identical to the HttpPost controller actions. Except with MVC you don't have to write left to write object.FirstName = txtFirstName.Text when you understand how UpdateModel works.
UI is UI. If you know HTML/CSS creating the UI is just as easy. Almost easier in MVC because you don't have to set control properties any longer and all UI can be done in one place.
Fast MVC comes from understanding how to get the most bang from your buck using EditorFor, DisplayFor templates. You'll need to know and understand how to customize your Object.ascx file. With this technique under your belt you won't have to create forms by hand anymore. 2 projects ago we had a site with 100% autogenerated forms. Change a class, change a form. Done!
Another helpful MVC tool is the DataAnnotations attributes. Validation made easy. Customizing these is really easy too. Just create your own ModelMetaDataProvider and starting expanding the validations your application can handle.
The only part of MVC that is slower is displaying a grid. MVC 3 already has a useful grid tool and MVCContrib has had a grid tool out for a year now. I ended up rolling my own, its very simple actually, loop through properties, write <td />'s. < 200 lines of code. This isn't really a benefit to WebForms either. To use WebForms grid components means giving up a lot of quality using ObjectDataSources and the like.
To summarize fast MVC comes from these different techniques:
Object.ascx
ModelMetadataProviders
UpdateModel
DataAnnotations
If you are more advanced and know ORMS like EntityFramework and how to use Automapper your probably going to be even faster.
You can get a demo up and running very quickly in MVC. I could put one together much quicker than with WebForms, and I am familiar with both.
The reliance on convention in MCV will help a lot, binding is based on the names of objects.
If i was creating a quick demo, i would just create a bunch of ViewModels with static data in them, different button clicks etc will just bind one of these ViewModels to the page.
Turbo Fast!
I build prototypes in excel. No logic, no code. just basically screenshots to show the user that we are communicating the same ideas. Create a worksheet for each "View" or screen you need to show. Client's usually only care how "pretty" an application looks vs does it work right.
This also is a benefit as you can include more non-technical users in the prototyping process, since most are used to excel. I can send you an example and the finished production web application, if seeing is believing. I personally learn best by example.
And to your post where you wrote...
I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
They need to have their expectations adjusted and managed. A lot of bad development has been done quickly over the years, which makes client's ask questions like "Bob did it in 1 hour'. To that I say, you can either have a lousy project fast, that you have to constantly duct tape or a well thought out and well written project that will only need to be enhanced as Bus Reqs change
I think the answer is obvious: use whichever you think makes you faster. There's no point in using MVC if you are faster in WebForms. Especially since this is for a throw-away demo.