In ASP.NET Core MVC (formerly MVC 6) there is a new area of functionality called View Components which appear to be a better alternative to Partial Views. I've seen the following View Component Example. But there doesn't seem much more information currently as to their usage.
I'm trying to evaluate if its worth using this pattern and if this can/(or is intended) to be used as a more baked in method to help with donut caching.
View components are definitively great and it's certainly an improvement. The one big improvement is that you can run asynchronous operations on view components where it wasn't possible with child actions.
More information available here:
Exciting Things About ASP.NET vNext Series: MVC View Components
For donut caching, there are two separate issues filed that you can comment/track: #1232 and #536
Currently there is available a brand new documentation from Microsoft:
View Components documentation.
In my opinion ViewComponents are very useful and flexible features. I like them, and I can recommend them.
However not always View Component is "a better alternative to Partial Views" - this will depend on your particular case.
Related
I was reading through some of the microsoft .net core documentation and stumbled across this page: https://learn.microsoft.com/en-us/aspnet/core/data/ef-mvc/
Does the following quoted text (more specifically the last bullet point) imply that the MVC approach is no longer the recommended approach moving forward? Is this just a microsoft thing or general for any development that was based on the MVC approach?
This tutorial teaches ASP.NET Core MVC and Entity Framework Core with
controllers and views. Razor Pages is a new alternative in ASP.NET
Core 2.0, a page-based programming model that makes building web UI
easier and more productive. We recommend the Razor Pages tutorial over
the MVC version. The Razor Pages tutorial:
Is easier to follow.
Provides more EF Core best practices.
Uses more efficient queries.
Is more current with the lastest API.
Covers more features.
Is the preferred approach for new application development.
Razor Pages are still MVC, they just greatly simplify your code. Rather than having a distinct Model in one directory, a Controller in another directory, and a View in yet another directory, it keeps everything together in two files: A "View" (.cshtml) and a "Controler/Model" (.cs).
If you look at enough ASP.NET MVC applications you quickly notice how often there is a 1:1 relationship between the Views and their Controllers. In most cases, you find the Controller contains one method per View that consists of little more than return View();. Razor Pages helps solve this issue.
This does not change the fundamental value proposition of MVC and it's clear separation of concerns. It also isn't an either/or proposition. You can absolutely mix the traditional MVC structure and Razor Pages in the same web app.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have an ASP.NET MVC 4 project and I'm stuck on an architectural decision on which JavaScript framework or library to use Angular.js or Knock.js. I am currently leaning towards using Angular.js over Knockout.js, but don't want to find out midway during project development I made a mistake.
Here is some background:
We need two-way model data binding
We need the ability to test views. I want to be able to do end to end unit testing. Also, we are using continuous integration.
"Save Changes" functionality. i.e. if a user makes changes on a page we need the ability to detect any changes and prompt the user to save their changes before they navigate away from the page
"Notifications" functionality. i.e. user will be logged on approximately 8 hours and will need to be notified and updated of changes made by other users (errors, data status changes and the like)
We need to "future proof" our application. Currently the business unit hasn't decided if we will need to support mobile devices, but I know it's just a matter of time.
Our team consists of developers with varying experience levels from very junior to senior developers.
Currently our models are complicated and may get even more so
We need to also consider RAD, code reuse, and maintainability
I have read the excellent answer here and watched Scott Allen's interview about Angular here
Since we are unable to change from our current ASP.NET MVC 4 architecture to use something on the server side like Web API I have some concerns in trying to implement Angular.js with MVC 4. Will this cause us to have two models one on the server and one on the client?
I am not looking for a "which is better" discussion about Angular and Knockout because I think they both have their pros and cons. I am looking for actual code on implementing a JavaScript framework or library in an ASP.NET MVC 4 application. I need a solution that I can live with 2+ years from now :)
Any ideas or suggestions? Maybe the answer is not Knock or Angular, but some other JavaScript framework?
my 2 cents worth.
preamble - i have worked with both angular and knockout.
I'm on my 3rd non trivial front end built with a MVVM/MVC lib.
I started with knockout because its MVVM is very similar to the wpf/silverlight mechanics. And it works well. The tutorials and documentation are top notch. All your coders will be able to work with knockout.js within days or if they have used mvvm under .net, then within hours.
However, these days I am using angular and will probably stick with it for the following reasons.
angular is a complete framework - knockout is really about just the 2
way binding. you still need other libraries like backbone.js/jquery
to do the rest of your work.
angular has dependency injection. which is perfect for adding
mocking for testing as well as giving structure to your code.
angular treats normal JS variables as observables within its $scope
object. that means you dont have to declare them in a special way
I'm not an angular fanboy, i still think they could move more over to the MVVM architecture instead of the "funky" MVVM/MVC hybrid architecture they currently have.
The biggest problem with angular is the documentation. Compared to knockout, it is woeful. It will add additional time and cost to getting your coders up to speed. Once they are there however, it is currently the best choice IMHO.
Glad to see this questions was of interest to the community ;) Just for completeness here's what I ended up doing:
I did go with AngularJS and ASP.NET MVC 4 and was glad that I did. Although, Angular has a steep learning curve but its worth it because of the power of directives.
We need two-way model data binding - On occassion I needed to set some initial values coming from the MVC controller. I used the ng-init attribute to accomplish this.
We need the ability to test views - I followed the AngularJS docs for testing
"Save Changes" functionality - I implemented this using a directive in Angular
"Notifications" functionality - I implemented this using toastr.js and and directives (schweet)
We need to "future proof" our application - I don't know Google's plans for AngularJS, but after working with AngularJS I can't see it going anywhere anytime soon and expected it to become more widely adopted :)
I don't have a lot of input on AngularJs, but want to provide some thoughts on Knockout.
Knockout is primarily a data-binding library to connect views to view model, but doesn't really provide a lot of capabilities beyond that. I wouldn't recommend using knockout alone as the main library to build a complex client-based web site.
You didn't mention whether you're implementing spa-like functionality (i.e. hash-tag navigation) or whether you're primarily using MVC server-side views (e.g. Razor). If you're just looking for quick data-binding on a per-page level, I would even reconsider that. To me, both of these (angular or knockout) are designed to enhance the client-side development experience - not so much a server-side approach such as MVC.
If you're considering an SPA approach, even in part, you'll likely want some framework that provides some level of control over the view activation life cycle.
As far as data-binding power and reliability, I believe in Knockout. I have been using it extensively, and have grown quite fond of it. If you like the feel of knockout, you may want to look into Durandal. Durandal is a decent framework is able to meet the needs of many "spa" web projects. It's a client-side framework built on top of several proven libraries, including Knockout. It's a little (lot) more light-weight than Angular, and possibly easier to user.
We are building a fairly large ASP.Net MVC web site using Durandal with Knockout in conjunction with an additional facade to tighten things up from a development standpoint, and the integration with ASP.Net MVC is straight-forward. I don't recommend trying to use the server-side knockout stuff that's out there; I just find that to limit the real power of the MVVM pattern.
I'm a long time ASP.NET WebForms developer. I'm familiar with MVC as a design pattern and have used it in many apps. I'm a little surprised (and excited) about ASP.NET MVC as I am moving a PoC into beta form using ASP.NET MVC,
Architecturally speaking, I have content templates that I will be using on the site to present content in different layouts. What will be the same across the board is that there will be images and text. How it's presented will depend upon which layout (or skin) the author wishes to use.
Architecturally speaking, which of the two scenarios fits better with the framework?
For each layout I desire, I create a single View and a single View Controller where the VC gets the info from the Model (images/text) and gives it to the View. The info from the model will depend on which article the user wants to see. To use a different layout, the view served would be a different view that contains that layout, and it would use the same VM and same Model.
or
I create a layout that has the layout which is then used by the view to present the content. The view could use a different layout to lay things out differently. Each article would have it's own view and when that view is loaded, a determination is made (based on author intent) which layout to use as the layout for the view. There would be multiple layouts that could be used.
Clearly both will do the job. I am new to ASP.NET MVC, so I am wondering, architecturally, what has been done in the past by those architecting similar cases.
I crossed the same bridge a while back and found that building up core "Base" partial Layouts for particular functionality worked in my favor. If you define base partials then you have a solid foundation for partials that extend that particular functionality using Layouts, moreover, if your controllers send base models to your base layouts then extended partials can build up on top of that. Please note that I am making use of a lot of AjaxBeginForm or pushing back smaller content within a larger model so what is described may be overkill.
I am developing a mobile application using ASP.Net MVC4.0, JQuery Mobile, HTML5.
As I am new to ASP.Net MVC, I am not sure whether to use Razor(.cshtml) or webForm(.aspx) view engine.
Can anyone suggest which view engine I can use to develop a mobile application?
Performance wise which is better, the razor view-engine or webform view-engine?
I don't think there is a performance aspect.
However, I find the Razor syntax beautifully terse. The HTML is far more prominent with Razor, which is what you want when you're developing HTML views.
In various MVC frameworks, view development encourages and requires
code written directly alongside markup. Because the ASPX view engine
was not designed with this goal in mind, the ASP.NET team decided to
build an entirely new view engine with a code-focused templating
approach. The result was a more intelligent parsing engine that is
able to very easily figure out where code stops and where markup
begins, without the developer needing to be very explicit.
There are even open-source view engines, that you might want to look at. For example, Spark View Engine.
Razor is the preferred View Engine for MVC, ASPX View Engine is the legacy View Engine and this option is there for backward compatibility. Here you will find a great article who explain the differences between both.
The ASPX engine is listed first. A site we are working on scaling is using only Razor views. Just having the ASPX engine before the razor engine was causing a huge amount to contention to occur when attempting to scale up the number requests. Doing this:
ViewEngines.Engines.Clear();
//Add Razor Engine
ViewEngines.Engines.Add(new RazorViewEngine());
at startup made a huge difference given that each page access was no longer looking for existence of aspx, ascx files. While it might not appear to affect performance on a single request, as you scale up and see contention and rising CPU percents, this is something one should check.
I am developing Sencha-Touch 1.1.0 MVC based mobile web-app. Before that I had checked, all application based on Sencha-Touch MVC having one controller. can you please tell me is there any memory issue or performance issue there if used more than one controller Secnha-Touch MVC and let me know what are the disadvantages of this.
I don't know where you had checked but most application in fact have more than one controller. There is absolutely no reason why to use only one controller and there are certainly no disadvantages if you use more than one controller.
It all depends on your app's business logic. In each MVC application you can use as many as you need models, views and controllers.