I'm starting to develop an application based on Hot Towel project template. The question is how I can scaffold Durandal?
I want to perform code generation like mvc scaffolding, but for SPA using Hot Towel template, to accelerate the development of the CRUD pages
Thanks for any suggestion!
Out of the box the Hot Towel project template is based on Durandal, Knockout, and Breeze. Durandal and Knockout work seamlessly with the MVVM pattern, and not the MVC or other MV* patterns.
The approach is not that different from the MVC pattern, my best suggestion for you on this is to follow what is given for you, and if it is not found to meet your needs, you can look at some other libraries or frameworks such as Angular.js or Ember.js.
There are more out there, but this would be the simplest way to decide if you are using what best fits your needs.
By the way, in addition to the pattern, it is worth noting that MVC scaffolding in an ASP.NET MVC project is all done on the server side with ASP.NET MVC controllers and basically generated views. Using a templating engine you could easily replicate the same functionality across all of your views by creating each of the CRUD operations (Create view, Read (details) view, Update (edit) view, and Delete views)
One thing that makes JavaScript libraries unique is that you can also combine all four of these functions into one and utilize a templating engine to share the functionality.
Related
I am new to net5 framework and have some questions regarding the structure of the project.
When we create a new project it will only create the razor pages. I am learning that we can achieve things with these razor pages.
Meanwhile, I have looked into some open source net5 projects on GitHub and see that they are also using MVC.
So, my question is why do we need MVC then? If everything is achieved using razor pages then what is the need for MVC?
If we need MVC then should we use razor pages with them too?
I have done the identity work with razor pages using scaffolding. What would happen now if I add MVC to my project. How will I manage the routes and page redirection from razor pages to MVC and vice versa?
Please help me with this so I can clear my concepts on this.
I will be really thankful to those who explain the scenario to me.
Thanks
First, .NET 5 is out of support. You should target .NET 6 instead.
Razor Pages represents a simpler way to generate HTML on the server compared to MVC. It is recommended for all new web applications that rely on server-side HTML generation going forward. MVC is still available for existing apps. It is also probably easier to migrate older MVC 5 (.NET Framework) apps to ASP.NET Core MVC when porting to .NET Core.
Razor Pages is built on top of the MVC framework and depends on a lot of the features of MVC such as model binding, action results and so on.
If you are using Razor Pages, there is no compelling reason to also use MVC in the same project, although you can. If you do, then you need to register controller endpoints:
app.MapControllers();
You might need to add controllers to your project if you want to create HTTP service APIs, although you can use the minimal API feature that was added to .NET 6 instead:
https://www.mikesdotnetting.com/article/358/using-minimal-apis-in-asp-net-core-razor-pages
Razor Pages can make coding page-focused scenarios easier and more
productive than using controllers and views.
https://learn.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-6.0&tabs=visual-studio
As another difference, in MVC, you usually create separate class for ViewModel. As I understand, in Razor Page, you don't need a separate class and you just add more properties in the same page and those properties will be part of your model which make things easier.
Currently we have a new menu item to our existing asp.net web forms application.
We have decided to go with MVC for this.
Please note that we have to share the same masterpages, css and Jquery files. We are currently planning to render the view inside a div in our aspx pages.
Is there a better way to accomplish this?
What are the limitations of our approach?
Can we leverage the MVC test cases in this approach?
Thanks
MVC is a stateless, disconnected architecture, you can not access the master page or aspx controls directly in the controller as aspx.cs does, secondly it is not possible to use the classic asp.net master page with mvc.
The things you can re use from existing project are:
UI Templates (design)
JS files
CSS files
Business Logic
Database
You can't use same master pages. You can't reuse ASP.NET MVC for some parts of your webforms view and vice versa. Either your view is completely on webforms or on ASP.NET MVC. And theoretically even mix of webforms with mvc in one web application could be problematic, but practically possible (see below point 1). So generally answer to your question is no.
If you are looking to ASP.NET MVC, you should think about step-by-step migration of your project to it.
Actually there are a couple of possibilities how to migrate
Mix in one project ASP.NET web forms and ASP.NET MVC. Technically it is possible. But it is some kind of hack. Your transition will be seamless but you can't your ASP.NET views. I will not recommend it. You can find this approach here http://www.devcurry.com/2013/05/adopting-aspnet-mvc-enhancements-in.html
In one solution use different projects for your webforms and mvc projects. In fact these are 2 different web application which typically could have common authentication, and there is question with webforms state. To solve problem with authentication you need create separate web service for it, which will be used by both. To solve problems with session state, use distributed caching for both, and try to change thinking from webforms state to caching, because mvc is actually stateless. Then for particular views you can redirect between views of both portals
I'd like to use for my next project Ext js and ASP.NET MVC.
I'm wondering what would be the best way of using this two framework together. So far I did some project using ASP.NET MVC, where every action method returned a view and reloaded the page. The Ext js mvc application uses a single page approach.
As I'm pretty new to ext js so I'm wondering if someone could share some experiences of building real world application using this two frameworks.
You can use extjs as you think is better for you. You can use its components as simple widgets or create a full javascript (extjs) client. However, which are the real requirements? a single page client or a traditional client?
In our current project we started using ASP.Net MVC Framework with extjs widgets, it was ok for a while but the customer wanted more and more sophisticated UI and a better user experince (among other thing) then, we changed the app, we left MVC models and controllers (views were removed) and we created a full javascript client with extjs 4.1.
After that we realized we were using an ASP M_C framework (with no views) and that was a nonsense so, we took the ASP MVC project away and replaced it by a WCF Rest service (it also could be done with an ASP.Net Web Api).
We feel proud of our decision and the resulting design. If you can, if you know extjs (learning it is rather hard) and javascript and, if you have support to your decision then, keep your application splitted in two:
a server-side service/api and,
a full javascript application.
Good luck!
I'm not sure I'd agree with the answer by #lontivero, I'm currently working on a project using ASP.NET MVC as the backend and ExtJS as the front.
You do, as pointed out, loose the V from the ASP.NET MVC stack and you end up needing to duplicate you C# view models in you ExtJS Models on the client side but I've found using MVC as a backend (effectively as a rest based collection of Json end points) absolutely fine.
You can utilise the model binding, model validation in MVC whilst leveraging the full client side js app in Ext.
I'm curious as to the points you didn't get on with using this structure (I'm not saying it's perfect, but it does seem to work)
We used Ext.NET (versions 0.x-1.x) in our previous projects. Even after a comprehensive effort to upgrade our projects to the (now current) version, we had to drop Ext.Net 2.x out.
If it fits you, it can help.
The main problems with Ext.Net were (several) incompatibilities with ASP.NET and a lack of trust. They used to keep their schedule, it's far from it for last 2 years or so. And they are behind ExtJS.
Some Background:
ASP.net MVC is primarly a paradigm shift in the way you structure and develop ASP.NET applications. Shifting from a "code behind" type of mentality to more of a standard MVC Ruby on Rails like mentality. I applaud it's efforts as a simlifying tool towards unit testing ease and seperation of code (although the html inline code could be debatable).
Expression and XAML is a way to describe the presentation layer that can be simple for designers.
The question is:
If we are to use ASP.NET MVC in developing our next website how does the design team that uses Expression and XAML supposed to create (V)iews or integrate into the development flow?
More specifically can Expression users still operate in an ASP.NET MVC world?
Note that the pages in Expression's model use a code behind paradigm as well.
It is a hack, but you can use XAML to render static images in ASP.NET MVC. Check out my post XAML Meets ASP.NET MVC - Serverside Image Rendering - that shows how to render XAML and WPF controls as an image in ASP.NET MVC
http://amazedsaint.blogspot.com/2010/07/xaml-meets-aspnet-mvc-create-databound.html
There is also the MvcXaml project that is a View Engine that allows for images to be dynamically generated based on a XAML view.
http://mvcxaml.codeplex.com
I will try to answer this, making several assumptions that may be wrong.
ASP.Net MVC is a web technology and XAML is a desktop one. You can use XAML inside Internet Explorer, but it's basically a hack, it works best for desktop or silverlight applications.
If you want a paradigm similar to MVC for the desktop, you should try the M-V-VM pattern, who is more appropriate to WPF and XAML.
With M-V-VM you can create views almost code-behind free.
A great intro to M-V-VM is this video by Jason Dolinger
If you are making a website using MVC and you are trying to integrate the design team, you should let them create the HTML+CSS views of your site, while the developers create the controllers and the models.
Please comment in this answer if I have misinterpreted the question.
I'm currently banging my head on these terms. However, maybe this silverlight-as-a-view-in-aspnet-mvc article will help? You've asked about XAML, and I thing this is what Silverlight uses...
When I first heard about StackOverflow, and heard that it was being built in ASP.Net MVC, I was a little confused. I thought ASP.Net was always an example of an MVC architecture. You have the .aspx page that provides the view, the .aspx.vb page that provides the controller, and you can create another class to be the model. The process for using MVC in ASP.Net is described in this Microsoft article.
So my question is. What Does ASP.Net MVC provide that you wouldn't be able to do with regular ASP.Net (even as far back as ASP.Net 1.1)? It is just fancy URLs? Is it just for bragging rights for MS to be able to compare themselves with new technologies like Ruby On Rails, and say, "We can do that too"? Is there something more that ASP.Net MVC actually provides, rather than a couple extra templates in the File->New menu?
I'm probably sounding really skeptical and negative right now, so I'll just stop. But I really want to know what ASP.Net MVC actually provides. Also, if anybody can tell me why it's Model-View-Controller and not in order of the layers of View-Controller-Model or Model-Control-View depending on whether you are going top to bottom, or vice versa, I'd really appreciate that too.
EDIT
Also, it's probably worth pointing out that I've never really cared for the web forms (AKA server controls) model either. I've only used it minimally, and never on the job.
.aspx doesn't fulfill the MVC pattern because the aspx page (the 'view') is called before the code behind (the 'controller').
This means that the controller has a 'hard dependency' on the view, which is very much against MVC principles.
One of the core benefits of MVC is that it allows you to test your controller (which contains a lot of logic) without instantiating a real view. You simply can't do this in the .aspx world.
Testing the controller all by itself is much faster than having to instantiate an entire asp.net pipeline (application, request, response, view state, session state etc).
Scott Guthrie explained it in this post "ASP.NET MVC Framework"
It enables clean separation of concerns, testability, and TDD by
default. All core contracts within
the MVC framework are interface based
and easily mockable (it includes
interface based
IHttpRequest/IHttpResponse
intrinsics). You can unit test the
application without having to run the
Controllers within an ASP.NET process
(making unit testing fast). You can
use any unit testing framework you
want to-do this testing (including
NUnit, MBUnit, MS Test, etc).
It is highly extensible and pluggable. Everything in the MVC
framework is designed so that it can
be easily replaced/customized (for
example: you can optionally plug-in
your own view engine, routing policy,
parameter serialization, etc). It
also supports using existing
dependency injection and IOC container
models (Windsor, Spring.Net,
NHibernate, etc).
It includes a very powerful URL mapping component that enables you to
build applications with clean URLs.
URLs do not need to have extensions
within them, and are designed to
easily support SEO and REST-friendly
naming patterns. For example, I could
easily map the /products/edit/4 URL to
the "Edit" action of the
ProductsController class in my project
above, or map the
/Blogs/scottgu/10-10-2007/SomeTopic/
URL to a "DisplayPost" action of a
BlogEngineController class.
The MVC framework supports using the existing ASP.NET .ASPX, .ASCX, and
.Master markup files as "view
templates" (meaning you can easily use
existing ASP.NET features like nested
master pages, <%= %> snippets,
declarative server controls,
templates, data-binding, localization,
etc). It does not, however, use the
existing post-back model for
interactions back to the server.
Instead, you'll route all end-user
interactions to a Controller class
instead - which helps ensure clean
separation of concerns and testability
(it also means no viewstate or page
lifecycle with MVC based views).
The ASP.NET MVC framework fully supports existing ASP.NET features
like forms/windows authentication, URL
authorization, membership/roles,
output and data caching,
session/profile state management,
health monitoring, configuration
system, the provider architecture,
etc.
Primarily, it makes it very easy to create testable websites with well defined separations of responsibility. Its also much easier to create valid XHTML UIs using the new MVC framework.
I've used the 2nd CTP (I think they're on five now) to start work on a website and, having created a few web applications before, I have to say its hundreds of times better than using the server control model.
Server controls are fine when you don't know what you're doing. As you start to learn about how web applications should function, you start fighting them. Eventually, you have to write your own to get past the shortcomings of current controls. Its at this point where the MVC starts to shine. And that's not even considering the testability of your website...
No more auto-generated html IDs!!! Anyone doing any sort of javascript appreciates this fact.
ASP.Net with it's code behind is almost MVC - but not - the one big thing that makes it not is that the codebehinds are tied directly to the aspx's - which is a big component of MVC. If you are thinking of the codebehinds as the controller - the should be completely decoupled from the view. The new .NET MVC rounds this out - and brings a complete MVC framework. Though there are existing ones for .NET already (see Spring.NET).
I looked through a couple simple examples such as this one. I can kind of see the difference. However, I don't really see how MVC uncouples the view from the controller. The view still references stuff that's in the controller. I do see how it makes it much easier to test, and that at least in MVC the controller doesn't have any knowledge of the view. And you wouldn't have to process the view to call methods in the controller. I can see that's quite a leap, even though at first glance it may not seem like much.
I do agree with #Will about fighting server controls. I've never worked in a situation where they were actually used, but many people I know who have, have run into quite a few limitations with them.
Article about ASP.net MVC Vs ASP.net Web form
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx