after thinking a lot about this we are going to give a try to ASP.NET MVC to upgrade a complex Web Forms project we have. Since we are new in MVC we have a lot of doubts.
Our project has an administration panel or backend with more than 70 pages and then a public site where we show all the information.
1) We are going to use MVC 5 and EF6 with database first. We love the way we can create all the entities without writting a single line and also how can we update the model when we change the database.
We have seen how you can create the CRUD operations with the scaffolding feature. This way also we save a lot of time, but is this the best way to do it?
2) At web forms we had different layers and then, in the presentation layer we have an "admin" folder where the backend pages are. The public pages are at the root folder.
How do you manage this in MVC? Since MVC uses VIEWS how can we separate both parts? Also, different parts use same Models, but what about controllers?
3) Is it storing the Models and Controllers in their folders the best structure? We used to separate the project in different layers, but that was for Web Forms, we don't know which is the best approach in MVC, What do you think?
If you separate in different projects, could you show us an example?
4) Also we used Telerik ASP.NET Rad Controls for Web Forms. Those controles are great for Web Forms and we also have the license for MVC, but are those good to use in MVC? Are necessary?
We have a lot of grids where we have to make some operations, show images, have buttons, upload images...
Are there any other options?
Thanks for helping. We are new in MVC but we hope we can learn fast because it seems amazing what you can do.
1) We are going to use MVC 5 and EF6 with database first. We love the
way we can create all the entities without writting a single line and
also how can we update the model when we change the database.
We have seen how you can create the CRUD operations with the
scaffolding feature. This way also we save a lot of time, but is this
the best way to do it?
You do not want to use scaffolding feature. As you said in other question that your have over 200 pages of Web Form. If so, you want to split the application into multiple layers with loosely coupled.
2) At web forms we had different layers and then, in the presentation
layer we have an "admin" folder where the backend pages are. The
public pages are at the root folder. How do you manage this in MVC?
Since MVC uses VIEWS how can we separate both parts? Also, different
parts use same Models, but what about controllers?
You can use Area.
3) Is it storing the Models and Controllers in their folders the best
structure? We used to separate the project in different layers, but
that was for Web Forms, we don't know which is the best approach in
MVC, What do you think? If you separate in different projects, could
you show us an example?
Look at open source projects such as NopCommerce, Orchard or Umbraco.
4) Also we used Telerik ASP.NET Rad Controls for Web Forms. Those
controles are great for Web Forms and we also have the license for
MVC, but are those good to use in MVC? Are necessary? We have a lot of
grids where we have to make some operations, show images, have
buttons, upload images... Are there any other options?
Telerik has Kendo UI. If you have DevCraft Ultimate, you can use Kendo UI
Professional which has MVC wrapper for Kendo UI. Basically, wrapper let you use HTML Helpers instead of hand coding JavaScripts.
Related
Learning new things needs an investment of time, space and energy. I am currently learning Asp.Net Core MVC 2.0. This ASP.NET Core tutorials overview states:
Razor Pages is the recommended approach to create a Web UI with ASP.NET Core
This information confused me in deciding whether I have to stop learning Asp.net Core MVC and start learning Asp.net Core Razor Pages.
Why is Razor Pages the recommended approach to create a Web UI in Asp.net Core?
Any directions are welcome.
From this article in Microsoft docs:
MVC: Using controllers and views, it was common for applications to have very
large controllers that worked with many different dependencies and view models and returned many
different views. This resulted in a lot of complexity and often resulted in controllers that didn’t follow
the Single Responsibility Principle or Open/Closed Principles effectively.
Razor Pages addresses this
issue by encapsulating the server-side logic for a given logical “page” in a web application. A Razor Page that has no server-side logic can simply consist of a Razor file (eg. “Index.cshtml”). However, most non-trivial Razor Pages will have an associated page model
class, which by convention is named the same as the Razor file with a “.cs” extension (for example, “Index.cshtml.cs”). This page model class combines the responsibilities of a Controller and a ViewModel. Instead of handling requests with controller action methods, page model handlers like “OnGet()” are
executed, rendering their associated page by default.
Razor pages simplify the process of building
individual pages in an ASP.NET Core app, while still providing all the architectural features of ASP.NET Core MVC. They are a good default choice for new page-based functionality.
When to use MVC:
If you’re building web APIs, the MVC pattern makes more sense than trying to use Razor Pages.
If your project will only expose web API endpoints, you should ideally start from the Web API project
template, but otherwise it’s easy to add controllers and associated API endpoints to any ASP.NET Core
app. You should also use the view-based MVC approach if you’re migrating an existing application
from ASP.NET MVC 5 or earlier to ASP.NET Core MVC and you want to do so with the least amount of
effort. Once you’ve made the initial migration, you can evaluate whether it makes sense to adopt
Razor Pages for new features or even as a wholesale migration.
Note:
Whether you choose to build your web app using Razor Pages or MVC views, your app will have
similar performance and will include support for dependency injection, filters, model binding, validation, etc.
Update: Some more reasons i read on this github issue commented by scott sauber:
We're using Razor Pages for a [complex] Health Insurance portal... We have 60+ pages and I can say that for Server-rendered HTML, I will never go back to MVC. It's also not just for simple things. The Health Insurance domain is inherently complex and combine this with the fact that it's a multi-tenant app (we sell the product to other insurance companies), which adds more complexity as the app is highly configurable as different insurance companies do things a bit differently.
Why use it?
Razor Pages is more secure by default. Razor Pages gives you AntiForgeryToken validation by default. Plus you opt-in to what properties you want to be model bound via [BindProperty] which limits your exposure to over-posting attacks.
Razor Pages has a better folder structure by default that scales better. In MVC, the default folder structure simply does not scale. Having separate folders for Views, Controllers, and often ViewModels when all three are ultimately tightly coupled to one another is a huge PITA to work with. You end up bouncing to all 3 folders and navigating a bunch anytime you need to add or change a feature. It's horrible. This is why I advocated for Feature Folders. With Razor Pages, your PageModel (Controller + ViewModel) are in the same folder as your View. You can just hit F7 to toggle between them which is also super convenient.
Leads to more maintainable code that scales better. With MVC it was super easy to bloat a Controller with 10+ Actions. Often, these Actions weren't even related to one another in any way (except maybe a Redirect between the two). This made navigating the Controller to find code very difficult. It got worse if there were private methods in the Controller too, further adding to the method bloat. With Razor Pages, it's nearly impossible to bloat up your Page Model with unrelated methods to your page. Everything you put in your PageModel is related to your Page.
Unit Testing is easier. With a Controller, you might have 8 Actions and some of your dependencies you inject in were only related to one or two Actions. So when unit testing a single Action either you need to mock those out unnecessarily or pass a null, both of which feels gross (this can be solved a bit with the Builder pattern). With Razor Pages, the dependencies you inject in are 100% related to GET and POST actions you're working with. It just feels natural.
Routing is easier. By default in Razor Pages, routing just matches your folder structure. This makes nesting folders way easier to accomplish. For instance, all of our HR Admin pages are under the /Administrator folder and all the Employee pages are under the /Employee folder. We can authorize an entire folder and say the person must be an Administrator to get to any subfolder of /Administrator, which was way easier to do that than with multiple Controllers that make up the Administrator features.
I think that's the big stuff.
Update 2:
This is about some complexity of MVC pattern, does not directly answer the question but can be useful: An Engineering Manager at Facebook, said (here) for their “sufficiently” large codebase and large organization, “MVC got really complicated really quickly,” concluding that MVC does not scale. The complexity of the system went exponential every time they attempted to add a new feature making the code “fragile and unpredictable.” This was becoming a serious problem for developers new to a certain codebase because they were afraid to touch the code lest they might break something. The result was MVC was falling apart for Facebook.
Razor Pages are optimized for page-based workflows and can be used in these scenarios with fewer moving parts than traditional MVC models. This is because you don't need to deal with Controllers, Actions, Routes, ViewModels, and Views (as you typically would). Instead your route is convention-based, and your PageModel serves as your Controller, Action(s), and ViewModel all in one. The page, of course, replaces the View. You also don't have to have as many folders as you would in MVC, further simplifying your project.
From ASP.NET Core - Simpler ASP.NET MVC Apps with Razor Pages, a Sept. 2017 MSDN article by Steve Smith:
[Razor Pages] provide
a simpler way to organize code within ASP.NET Core applications, keeping implementation logic and view models closer to the view implementation code.
They also offer a simpler way to get started developing ASP.NET Core apps,
That article has more information on why to use Razor Pages over MVC for page-based workflows. Obviously, for APIs, you will still want to use Controllers.
3rd party edit - disadvantages of classical MVC folder organization
ASP.NET Core - Feature Slices for ASP.NET Core MVC, an older MSDN article from Sept. 2016, describes why the classical MVC convention to organize views and controller might have disadvantages for larger projects. The article gives an example of four loosely related application concepts: Ninjas, Plants, Pirates and Zombies. The article outlines a way to structure them outside of the default folder convention by organizing files into folders by feature or area of responsibility.
Microsoft is coming back to the WebForms approach to simplify the project structure trusting in the "Convention over configuration" mantra, while hiding the configuration from developer to make things faster. But it has the disavantage that everything will be mixed again. It doesn't look like a smart move for organizing. But... Hey! Something new must catch the attention of the dev towards Microsoft.
If your page uses an MVC Web API for the REStful, it's really more easy to just use Razor pages. If not, I would recommend you to use Core MVC.
In huge projects, where the model and controller are together in the same file, maintenance will be a nightmare. It works well for clases that are just 2 properties long, but it violates the Open Close Principle of OOP. You should design and use an architecture that can grow with time (Extensible) and still be stable and logic(No reestructuring the project), just extend it using the same pattern.
As a Software Architect I use design patterns automatically. What I like a lot is the Facade design pattern. You hide everything related to Home behind a HomeController and you can do the same with Repositories.
Want to know a funny thing? A tour guide explained where the name
Facade comes from. In Amsterdam you have big houses across the waters.
From the outside they look luxureous. But from the behind they can be
messy. The facade of the house hides whats behind it. Design patterns
comes from the building world. Well whats behind in my applications
also looks good but it was nice to know from the tour guide about the
explanation.
What about support for Sharing and Grouping actions in Razor pages. If you look at MVC Controllers you can see that you can Group controller actions based on functionality. You could say the Home page is such a functionality. Then you have a HomeController with About() and Contact() in it, but with Razor Pages this would be different pages. May be you have a big HomeController with lets say 5 other Views in it. They can all be grouped in the same HomeController.
A Controller has two things a Razor Pages does not have:
Sharing: You can share Controller actions between different pages, sometimes controller actions are not bound only to one page but can be shared between several pages. Remember Controller actions can also only return Data (JSON/XML/etc). Sometimes what they return can be used by different pages too.
Grouping: You can group related Controller actions together in one Controller. Ok if you are a fan of small Controller files you won't do this. I do. I group my Controllers based on functionality. That makes navigation much easier.
What is the Razor pages way of handling this: Use of directories I think:
Grouping: If we have the HomeController, then we could make a subdirectory Home with all the Home pages in it.
Question: For a simple Home that would be enough. But lets say we have an XController that uses for all actions the same Repository. You could initialize that Repository in the Initializer function of the XController. But for pages in the X subdirectory you would have to do that for all X actions again. Is that DRY?
Sharing: You could make a "Share" subdirectory and under that, directories with functionality that should be shared between pages.
Question: If you look at my fix you can see I use directories to solve the Share and Grouping problem of Razor pages.
How would you do this?
or...are Razor pages just meant to be for simple websites, could this be the conclusion for this version of Razor pages.
Blazor server has a strange architecture. It looks like a chat application by use of SignalR. My experience with applications like that is that events can get lost. I don't want to lose events, better is they are stacked and guaranteed to be processed like mail.
Developers were on forums in 2013 asking "What does Microsoft mean, Silverlight is not the recommended ...???"
Only this time, it is that MVC is going to be pronounced dead and long live MVVM.
And you can likely expect MVC to be thrown to the scrap heap, slowly, but sped up in about 18 months from now, and any and all time you spent learning MVC will go to that same scrap heap.
Also, MVVM looks easy but it takes a year to get the hang of it and really do it right.
I've looked all over the web for the best way to organize an ASP.NET MVC2 project. I've only seen examples of people using the default template for MVC2 projects. But is this the best way to organize your project if it is going to contain a large number of files?
We're in the process of building an application that is heavily built around jQuery for UI and ajax using JSON. So, as you can imagine, we will have many custom .js support scripts.
In our solution, we have placed all our support libraries (3rd party and custom) into respective projects. The MVC2 project that is also in the solution is using the default MVC2 template.
In the MVC2 project, the "starting" structure is still pretty much unchanged. Under the Controllers directory, we have each controller AccountController.cs and HomeController.cs (for example). Under the Views directory, we have three subdirectories named Account, Home, and Shared. In the Scripts, directory we have also divided that up with three directories, Account, Home, and Shared. And finally we have the Models directory, that is also divided into Account, Home, and Shared subdirectories.
As you can see we haven't deviated from the basic template that much. But, as we start adding stuff to this, we're realizing how cumbersome this might become when we get upwards to 20 or 30 views and 100 support .js files.
Any suggestions would be great!
Thanks.
Look into using Areas to organize your Views/Controllers/Models/Content.
Here's a good article from Microsoft: Walkthrough: Organizing an ASP.NET MVC Application using Areas
To accommodate large projects, ASP.NET MVC lets you partition Web applications into smaller units that are referred to as areas. Areas provide a way to separate a large MVC Web application into smaller functional groupings. An area is effectively an MVC structure inside an application. An application could contain several MVC structures (areas).
I plan to pick up Silverlight in the future.
Possibility of going into Microsoft WPF.
Currently learning Objective-C 2.0 w/ Cocoa.
I already know Pros and Cons of ASP.NET MVC vs ASP.NET Webforms. What I want to know is what would be more "efficient" for me to learn given the circumstances above?
By efficient I mean learning one design pattern once and then re-using it. Objective-C I believe uses MVC approach? What about Silverlight? WPF?
I'll be going to B&N tomorrow to pick up an ASP.NET book so I need to decide right now between webforms and mvc.
Also as a side question is it true that ASP.NET Webforms is often used by freelancers/small companies and ASP.NET MVC in large enterprises?
I truly believe that ASP.NET MVC is more aligned to how the web works as winforms, but that doesn't mean anyone should just ditch ASP.NET Webforms and just use ASP.NET MVC. I think you should attempt to look at both, regardless of what your future plans are.
As far as I can tell, the pattern used commonly amongst WPFers is MVVM (Model, View, View-Model).
As for your last question, regarding the use of ASP.NET MVC in large enterprises vs ASP.NET Webforms in small companies. I believe that you should pick the technology (talking specifically about mvc vs webforms) that suites your coding style the best.
There are advantages and disadvantages to both.
I second PieterG's comment and would like to add:
If you are looking to learn a platform on which you want to put different kinds of view layers on top, I would highly recommend MVC over Web forms. Another way to ask the question would be: in your application, does data have first class status?
I build mostly reporting applications, so the answer for me is: yes!
Based on personal experience, its a lot easier for me to build a set of ReSTful controllers which handle business logic. Then when I want to push it to a RIA front-end (I do Flex), all I do is add another ReSTFul method to get me the data in XML so I can work with it in Flex. So, for example if I have Urls like this that return HTML (i.e. aspx) pages:
example.com/stuff/
I can then add a method (or even just a route in the route table) to do this:
example.com/stuff/xml
In other words, I am able to turn my controller into a data service with minimal effort and this has worked very well for me for exporting to XML, Json, even Excel. Doing the same in web forms is very painful.
I want to implement rich reporting features in one of our asp.net mvc based web applications. The required features in the reports are
Graphs
Charts
Grouping, sub totals, page breaking, etc
Ability to export to excel, pdf, csv and other formats
Printing Support
We are ready to purchase commercial controls(if free ones are not available). Please suggest us the best of available options.
I do not know what rich reporting packages are out there that are 100% ASP.NET MVC-driven. I've seen a few talk about MVC.
But technically, you don't need an MVC-version of reporting controls. ASP.NET MVC allows you to use standard ASP.NET functions, such as WebForms, postbacks, server controls, etc. This is easy as a drop-in-place solution because ASP.NET MVC's default Convention-over-Configuration programming checks to see if a directory or file exists first, before being routed through the controller logic.
So, if there are no Asp.Net Mvc versions of graphs and charts you like - then fear not, you can fall back to the ones you've used for your previous asp.net forms projects. Even though I recommend sticking it into a dedicated directory (i.e. /reports) to keep a clean website.
I suggest you try and use a regular web form for the reports, with graphic, charts, and any other ontrol you might need. MVC views and web forms can live in the same project, noting wrong with that. At least until you find a way to do it using a MVC view.
In my own opinion, you don't have to do everything MVC in a project, you are "allowed" to do whatever you need to do to make your application work the way you want to.
You can use the asp.net chart control which is free to download and supported with ASP.net MVC
I found this while searching for something similar.
http://www.componentsource.com/products/syncfusion-essential-studio-aspnet-mvc/index-gbp.html
I haven't used it though. There is a trial download.
I was curious how in the typical ASP.NET MVC mentality one could build a platform that others could develop plugins for. I mean, how would those plugins look like?
Like exiting user controls for WebForms, encapsulating all layers in themselves, or three different files representing the model the view and the controller. I should develop the core of a CMS, that I'd like others to build plugins for later on. Which mentality is better for that, classic Web Forms or ASP.NET MVC?
I need developers to be able to separately build components for that. Is it possible to encapsulate the MVC directory structure in a component DLL file and then when I reference the DLL file, to be able to directly access the component's model, view, or controller as part of the general MVC structure?
The most promising component techniques have come from the guys over at lostechies.com and Mvccontrib in the form of Portable Areas. Portable Areas allows an entire MVC app to be appended onto an existing application. So its not just a UI component but also provides all the work flow and screen integration as well.
Open Forum does something like this as well. I don't know how, but it is very plug and play.
For straight up plugin architecture there is an interesting screencast and source code for Rob Connery's link text. He takes advantage of the App-Code directory to slide new plugins into place without having to edit the main site.