I am thinking of using upshot.js along with Knockout in one of my very important projects. I do not see any documentation or any activity around upshot. Before I commit to this decision, is this project still active?
If the entire asp.net stack is now open and one can see what is getting committed to repository, why this small library is still not on codeplex or github for community to see?
I hope this is still on radar of asp.net team.
According to this blog post, Upshot is officially dead:
http://www.riaservicesblog.net/Blog/post/WCF-RIA-Services-is-Dead-Long-Live-WCF-RIA-Services.aspx
The author points to BreezeJS as an alternative:
http://www.breezejs.com
Upshot is officially dead.
"Earlier this year the Beta version of Visual Studio 2012 included a template that was designed for building “single page applications” using Upshot.js and a special Web API-based DataController that provided support for insert, update, and delete operations using the unit of work pattern with transaction support. We are not currently continuing work on that template or Upshot.js. We want to first focus on improving the development experience with existing popular JavaScript libraries and in future versions we will revisit this decision and see if additional libraries are needed to round out the SPA experience."
http://aspnetwebstack.codeplex.com/wikipage?title=Roadmap
Give a shot to JayData at http://jaydata.org, it has JavaScript Language Query and JavaScript CRUD capabilities with change tracking, batches and a lot more. What it offers over BreezeJS is its provider agnostic architecture and a number of providers that you can use out of the box: OData, webSQL, IndexedDB, localStore, Facebook and YQL.
JayData plays nicely with NodeJS and let you consume OData from a JavaScript based middletier.
Also you can use JayData not only to consume but also to provide OData if you are using it on the server side with NodeJS and mongoDB.
The ASP.NET team haven't finished the official release of ASP.NET SPA in time to ship with the final ASP.NET MVC 4 release but they are still working on it.
You can find the source code for ASP.NET SPA and follow the development effort on the ASP.NET CodePlex site:
ASP.NET SPA Source Code (to look at the upshot stuff click Browse and expand src/SPA/upshot
ASP.NET SPA Discussions
The general lack of documentation is caused by the fact that there haven't be an official release yet.
Speaking for my company - we used exactly the same combination (Knockout + Upshot) and after sweating a lot of blood, we decided to get rid of Upshot and replace it with JQuery's ajax calls. Much more transparent and much more bugfree. However, much more code, too.
Back in February the authors of Upshot promised they would put documentation on in a week or so and since then I've heard nothing of them. If you want my opinion, I think this project has already been buried or indefinitely postponed.
Accodding to what is said on the discussions(see http://aspnetwebstack.codeplex.com/discussions/topics/5321/asp-net-single-page-application) on SPA, the whole SPA strategy would change, so I think the final version o SPA or whatever will replace it will be quite different from the actual bits...so I don't know if it is a good move continuing using the actual version...that at my bets knowledge is not compatible with Mvc 4 RTM.
I am the author of the Mvc Controls Toolkit there we implemented some js functions to help querying OData, and to update entitiess that are on the client side. They handle validation errors(both client side and server side), return to client principal keys created on the server, do changes tracking (to send to the server just changed entities) and allows undoing changes done on the client side. They handle also one to many relations. Moreover, updates are handled not only with WebApi controllers but also with normal controllers.
Give a look to this first tutorial: http://dotnet-programming.com/post/2012/04/03/Mvc-Controls-Toolkit-Support-to-Mvc4-WebApi.aspx
and then refer to the other tutorilas linked.
Related
I recently developed an application using HTML5 and KendoUI suite and I found it much quicker to develop than using MVC or ASP.Net.
Since HTML5 is getting so much support from vendors and with tools and platforms like PhoneGap and Windows 8 apps I was wondering what arguments will be made to rather choose MVC over a HTML5 client?
I am just trying to get some constructive motivations for and against going HTML5 client only and not making use of ASP.Net MVC or any other Server side technology to generate client HTML.
There are hugely complex things you would never be able to do without some type of server side data processing, unless your app is just trivial. Given the choice I would never go back to ASP.Net, but MVC4, Razor, EF5, Kendo and HTML5 are like greased lightning. You have the choice of emphasis on a case-by-case basis to choose where it is most appropriate to solve a particular problem in this ecosystem. You can still lean very client-side if you wish. Properly architected things have their place though and I find the MVC model gives me almost any flexibility I need. I don’t really consider MVC to be generating my HTML client code per say, but to be a facilitator, which makes me curious if your prior MVC projects may have tainted you with too much server-side reliance. But ultimately we should be crafting the solution from the problem, not trying to solve every problem with the same solution, so your query could be completely on the money. (I believe I have said nothing.)
I'm investigating technologies to build a commercial SaS site for a shop that predominantly uses Microsoft technologies.
The idea is that the site will have pluggable modules, with features that are either free or paid. Customers will be able to chop & change between features, & have their billing adjusted automagically as they do so.
If I were rolling this myself, I'd use:
.NET 4 / VS2010 / C# / ReSharper / NUnit / Moq
NDependencyInjection
SQL Server
LINQ to SQL
ASP.NET MVC 3
Authorize.net (or possibly billing hand-off to SAP)
Selenium
... and hand-roll an IOC-based plugin architecture (e.g., there is some good discussion on ASP.NET MVC plugins here and here).
But at this point I'm wondering - has this been done before? I'm imagining some sort of vaguely CMS-like architecture with built-in plug-in, commerce & subscription stuff. All of that, rolled up into an 'off the shelf' solution, either FOSS or commercial.
Can anyone recommend such a solution, or is it simply a 'roll your own' job? I think DotNetNuke might be worth looking at, but would appreciate feedback from people who've used it in production for this sort of task.
Edited to add: DotNetNuke appears set on continuing with WebForms, which is a big turn-off for me at least. As one of the commenters on that post said, it's an evolutionary dead-end.
Edited again: Silverlight is definitely out for this project. We need to support a wide range of devices, including non-Microsoft mobile devices like Android and iOS tablets & phones. We do need a reasonably rich UI but we'll be doing that in Javascript.
For a project which needed plugable modules, I've used MEF (which comes built in to .net 4.0).
By using this great code for compiling views into a dll it was easy to use MEF to load additional views and controllers making extensability easy.
The only other thing i'd do differently to your suggestments is to use Linq to Entites rather than Linq to Sql. The latest code-first version makes it very quick to get things up and running
Martin
I've done a similar solution for a VOIP PBX solution. I've made everything myself using nhibernate, autofac and a couple of own libraries. It's not really different from doing a normal application.
The most important aspect you need to understand is that ALL modules are loaded at ALL time. Theres no way around that if you need a solution that works well (you could jungle with one app domain per customer but that's not very inefficient).
You should instead control authorization using the standard .NET CAS (Code Access Security) solution. You do this by creating your own IPrincipal and IIdentity. The principal should correspond the tenant (organization) while IPrincipal corresponds to the user.
I use a ITenantEntity interface (contains the tenant db id) on all of my classes/entities which should belong to a tenant. It's used to validate that the currently logged on user really have access to the entity requested.
The hardest thing is if your application is multithreading (for instance if you got a background thread or timer doing some maintenance). The reasons is that it's quite easy to forget to switch to the correct IPrincipal which makes all your CAS checks fuck up. The easiest way to go around that is to create a custom Timer and Thread classes which forces you to specify a IPrincipal (or at least makes it easy to switch).
Another common approach is to use the tenantId argument on all service / repository methods. But that isn't a very robust solution imho.
Why would anyone roll these in an 'off the shelf' solution?
These parts of the architecture are quite independent and you can substitute for whatever suits your needs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I find myself on the edge of trying out ASP.NET MVC but there is still "something" holding me back. Are you still waiting to try it, and if so, why? If you finally decided to use it, what helped you get over your hesitation?
I'm not worried about it from a technical point of view; I know the pros and cons of web forms vs ASP.NET MVC. My concerns are more on the practical side.
Will Microsoft continue to support ASP.NET MVC if they don't reach some critical threshold of developers/customers using it?
Are customers willing to try ASP.NET MVC? Have you had to convince a customer to use it? How did that go?
Are there major sites using ASP.NET MVC (besides SO)? Could you provide links if you have them?
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
If you have any other concerns preventing you from using ASP.NET MVC, what are they?
If you had concerns but felt they were addressed and now use ASP.NET MVC, could you list them as well?
Will Microsoft continue to support ASP.NET MVC if they don't reach some critical threshold of developers/customers using it?
They will for sure.
Are customers willing to try ASP.NET MVC? Have you had to convince a customer to use it? How did that go?
Customers care about high quality products and price. Just convince them that Mvc will help to raise quality and lower price. Shouldn't be hard.
Are there major sites using ASP.NET MVC (besides SO)? Could you provide links if you have them?
Isn't it enough with SO? :)
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
I did try and didn't regret it at all. It kills me being forced to work on web forms project again.
Go for it!
I believe ASP.NET MVC has reached that critical threshold, as evident by VS 2010 tooling, ASP.NET, MS employee blog and the extensive effort Microsoft put into the framework thus far. I don't see this framework perishing in the next decade (or two).
By customers, I assume you mean people that I build websites for? The only issue I find with ASP.NET is the hosting solutions. However, this issue is becoming moot as more affordable hosting solutions are found. But usually, if I believe in the technology and that it will work for my customer, my customer trusts me and agrees on it. The customer is also usually comforted by the fact that ASP.NET-MVC is a Microsoft product. Having a big company behind a technology is always a nice thing to have, since you can rest assured it will be supported for quite awhile with frequent updates.
ASP.NET MVC is a relatively new framework, and slow adoption of new technology is expected. But this is what I found: http://weblogs.asp.net/mikebosch/archive/2008/05/05/gallery-of-live-asp-net-mvc-sites.aspx . I think you'll see a big influx of websites using ASP.NET-MVC this year when VS 2010/.NET 4 are released with built-in support for ASP.NET MVC.
I never enjoyed developing with C#/ASP.NET more than when I started using ASP.NET-MVC. To a certain extent, ASP.NET-MVC forces you to write good code more so than WebForms due to ASP.NET-MVC inherit separation of concerns and easy customization. And the ability to control HTML output is essential, a feature that was difficult with ASP.NET-WebForms (pre 4.0).
I use MVC and hate it, especially, the front end, web form are far more better in the front end... With loads of javacript on the page, that means it is hard to maintain and take a longer time to develop and debug..
To do a very complicated page, the flexibility of MVC is limited, you will end up with using a lot of javascript control, and you know what? Different controls use different version of jquery, and they have conflict..
It is actually the javascript, and lack of UI flexibility that pulls me off, especially you are NOT working on your code
and we have more issues of browser compatability, with the new browsers coming, you are going to shoot yourself with MVC
MVC front end is very fast if your web site is not too big.. The backend of MVC is very good, it is the front end that blows it over
Why not? The rest of my team doesn't want to.
I have not yet actually tried coding up some ASP.Net MVC(looked at a few examples though) but the main thing holding us back from using it is that all of our code is currently written using Webforms.
Regarding Microsoft support ASP.Net. First Scott Guthrie, the VP of Development at MS is behind it, so that's one feather in its cap. Second its open source now so even if for some strange reason MS decides not to support it going forward you can still tweak it on your own if you need to. In addtion the MVC pattern is somethign that more and more web development platforms are using. It is a great pattern for web development and as a result I can't think of any reason MS wouldn't continue to support it.
If by customers you mean end users, honestly they shouldn't care how you implement the site. If by customers you mean consulting clients, if you can develop faster and they have the servers that can host it, I would think they would be open to it. On top of that youre MVC sites should use less bandwidth than a typical Web Forms web site (IMHO) mainly because there is a lot of additional stuff put into a Web Forms page (for example extra attributes in the HTML htat are tailored for web forms, ViewState) so that should be seen as a positive by them. Now if by customers you mean people integrating with you, then its also a plus since MVC makes it very easy to implement REST based web services (not that WFC doesn't but MVC works very nicely as well).
Hmm major sites using MVC, so far I've found a list here I also know of a number of apps at different companies where large scale MVC apps are in development. I wish I could give more detail, but unfortuantely I can't at the moment.
When I first started out with ASP.Net MVC I thought I was going to hate it. I wasn't a huge fan of Web Forms either, but MVC just felt like a step back to ASP development back before .Net came out. Then I started really getting into it and really finding the pattern is clean, concise, extensible, maintainable, and easy to pick up. Honestly I don't want to ever go back to Web Forms, and anytime I find myself doing a .Net web app I make a point of making it an MVC project.
You need to choose what's more appropriate to your product. Webforms has a few things to recommend it over mvc in some situations.
The big one is a developer working on in-house tools at small to medium shops. In these circumstances:
Large viewstates are not likely to be a problem, because your users typically have 100Mbit upload to your web server rather than a measly 128Kbit or less.
Javascript is likley to be supported by everyone
Development time matters more than widespread cross-browser compatibility or even nice design.
You're likely stuck working with inherited devs who used to do desktop/forms style development, or have a lot of churn among junior devs who don't really know web development.
All of those things together mean that webforms is still a very good fit. And let's be honest: a lot more programmers work at these small to medium in-house shops than do public internet work. So webforms isn't going anywhere.
That said, one of the big things coming up among these small shops is likely to be taking their internal tools and making them available offsite for telecommuters. In that situation, you need to start worrying more about WAN performance odd browser issues where MVC might be a better fit.
Dell is hiring masses of ASP.NET MVC developers in Texas and India for major work on many of their websites.
According to The Gu, ASP.NET MVC will have it's own product and development cycle. It is now 100% detached from ASP.NET WebForms and it's not going away.
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
I do not regret trying out MVC in fact I love it. When I started it out I hated it I kept looking for the code behind file and was unsure at first how to get values out textboxes and stuff without going textbox1.Text;
Now I cringe every time I go back to webforms and wish I could write it in ASP.NET MVC because I just love how your working with html instead of using drag and drop controls that usually make your life alot harder if you got to customize them to much. I love how ASP.NET MVC likes to focus on good code like design patterns such as the Repository pattern and how to do unit test using TDD.
I have not picked up a book yet in MVC where they talked about how to make good code. I am not saying you can't write good code in Webforms but in the books and classes that I seen teach ASP.NET this never seems to be a main focus.
Like for instance I hate the datasource controls I am tutoring some people in WebForms and they love to drag a datasource in and then write their SQL statements in that datasource. Then in the code behind they use these datasorces to insert their records.
So every time they need to make a new SQL query a new datsource is dragged on and made. So now you all your logic is all mixed together. It makes it so much harder to find out whats going on, switch to different things if needed then of course it is limiting.
Something that revolves around the name "controller" can only mean problems.
I tried following the Nerddinner http://www.asp.net/mVC/ tutorial this morning. I'm comfortable in webforms, but nothing in that nerddinner tutorial made sense, just an outdated, hardcoded recipe from mvc1.0 that dosent even compile with the current mvc2.0, probably Wrox made this tutorial, only they can come up with only formating and no content.
I didn't see anything in there that was good; a bunch of hardcoded conventions I didn't need.
I certainly didn't see anything in there that would make me say I'd want to move from webforms, although this seems to be all the propaganda I read.
They put this tutorial based around wizards, on http://www.asp.net/mVC/ main page, while claiming the model is lean, all of it is generated code they don't explain, the default mvc template project has something like 15 references.
This 2 page website managed to be slow to build and to load.
Was 30 minutes in it until I realized my data model didn't match the one from the tutorial and many things that had been generated using the create controller and create view wizards were now failing.
With what I was provided in the rushed tutorial, I wasn't able to recover the project. I'll just pass until I find better documentation.
I'm curious to know if any basic CMS code has been written for ASP.NET MVC.
The reason I ask is, I'm making a data-driven website for a client, and I've already spent a significant amount of time building it from the ground-up in MVC, but now the client wants content management facilities.
Basically they want to be able to add/edit/remove articles and have revision control.
It would be great if I could somehow 'bolt on' the content management without having to start again from scratch, developing it under an existing CMS.
Should I build the article management and revision control myself, or should I re-use some existing package?
N2 does what you describe - "bolts on" to existing ASP.NET solutions (including MVC).
Also, kooboo is interesting http://www.kooboo.com
(I know this question is old, but it still comes high up for the relevant search terms.)
Today I discovered Meek, http://www.adventuretechgroup.com/labs-meek/, and it was very simple and unobtrusive to add to my MVC project, which I believe is what the original poster would have wanted - bolting on CMS as a feature rather than having it take over your entire site.
Piranha CMS is well suited to bolting on to an existing application. The author of it describes why and how here. To quote straight from that source:
"Our focus is content management and to have a transparent and lightweight API for developers. Piranha CMS has almost no components or helpers that render any HTML at all, it simply provides a database, a manager interface and a routing mechanism for retrieving the correct data for the current request.
In the case of you having an existing website you could actually bypass the routing completely, add one page at a time in the manager interface and then manually load the Page model in you existing page. This would allow you to keep your original application exactly the same but manage the content form the manager interface."
If you are still looking, I've published my new open source CMS here:
MVCwCMS
I'm actively working on it so I will push more updates soon.
Here is also a quick summary as to how Telerik Sitefinity does it:
http://www.sitefinity.com/mvc-cms
in brief - allows you to plug in standard system.web.mvc.controller classes as widgets, lets you use the API for anything including model binding, standard Razor for a view engine etc.
There is also Oxite which I believe is more of a blog engine.
Heve a look at AtomicCms it's a free open source content management system based on ASP.NET MVC 1.0
http://atomiccms.codeplex.com
Check for Orchard ;-)
It is based on asp.net mvc.
I've read all the marketing speak about how mvc and webforms are complementary etc...
However it seems that all the blogs talk about is mvc and the only news coming out is about mvc.
Is Microsoft going to continue to IMPROVE webforms as a first class citizen or will it just be a supported technology as they move all their real efforts, developers and resources to mvc over time?
Is there any real evidence of any new exciting improvements coming to webforms in the near future?
You could do worse than take a look at Phil Haak's post from November:
The Future of WebForms and ASP.NET MVC
He points out 5 key things anounced under ASP.NET at PDC last year:
Core Infrastructure including scale and performance
Web Forms including issues with Client IDs, ViewState, CSS use, etc
AJAX
Data and Dynamic Data
MVC
Coupled with that, there are things that have been built as part of ASP.NET MVC that have already been released for webforms like the Routing module which is going to be great help in some of my projects, even without using MVC.
On top of those, there are also a number of changes coming in VS2010 that should help web developers using either WebForms or MVC, which would be good.
Bloggers tend to talk about what is shiny and "new", that's the way things go - you're bound to see a lot of words written about it because of that, although MVC is hardly a new design pattern - it goes back at least 30 years.
The same could be said of WPF/Silverlight - are they WinForms/WebForms killers? No. They are alternative offerings, with some benefits over the earlier way of doing things, but also with some differences/drawbacks.
I was at a conference (Remix 08) and Scott Gu said they will definatly be continuing to support both methods and that MVC was not appropriate for every application. Scott said there were a number of coming improvements for web forms model (although didnt say what they were).
The web forms model will not disapear because:
Web forms model is better for some types of applications, e.g. small apps, those requiring long processes that make use of view state useful
Many applications are using it
Many third party components developed for it
ASP.net implementation is not mature yet (although does seem pretty good so far)
Microsoft will probably announce a number of new features in PDC in a few weeks time.
Microsoft is finally coming to terms to one basic fact of development. You can't provide the ultimate solution to any problem. This is why MVC is being developed, and Scott Guthrie is clearly stating that MVC is meant for larger, more enterprise-y sites. Web forms will continue to exist and be developed as a simple, RAD-based approach to web development.
If you take a step back and review all recent improvements and additions to the Microsoft stack, you can quite easily categorize them between these two classes. For example:
Data access: LINQ-to-SQL vs EntityFramework
Remoting: WCF vs WebServices
LiveID: LiveID (web) authentication vs RPS authentication
...
I only hope that Microsoft will make this distinction clearer with time, because there seems to be a lot of confusion among developers as to what tool should be chosen for which task.
In conclusion, I think that Microsoft will keep on developing both because they cater to different developer profiles. Microsoft has obviously a lot of interest in growing its developer base as much as possible and to make the .NET stack as useful as possible.
I am going to go out on a limb here and disagree with the general idea that MVC is the "enterprise" framework here or is somehow the better of the two.
MVC is great! But just look at the name. It stands for "Model, View, Controller"... see the "view" in there?
Now look at the competition, "Web Forms"... see the "forms" in that one?
MVC does a great job in "view" type situations. For sites that publish content ("views" of information) MVC probably has an edge, especially for larger systems that need a lot of testing and very a formal design to support intelligent view switching.
For applications that interact heavily with the user via forms (data collection and data entry heavy apps) web forms has an edge due to the inherent use of form posts as a primary mechanism.
While you can do views with web forms and you can do forms with MVC, each has trade-offs. In the current state of MVC, I find that writing heavy data entry "views" is much more difficult and painful than with web forms... and I don't mean a little bit.
In the future I do expect to see MVC get better with dealing with data entry scenarios, but these scenarios will likely come at a pretty high price compared to doing those with web forms.
Neither is more "enterprise" level than the other as far as I can tell... what I'm most interested in going forward are hybrid applications that use MVC for the display and publishing end of the business while web forms are used more naturally for heavy data entry end... all in the same web project... I sure hope we see something like that.
Before word of the MVC framework started spreading, we spent a good deal of time at my company developing our own .NET MVC framework.
This was because we didn't want to be constrained by the limitations of the WebForms abstraction - we wanted to avoid the 'clunky' feel and user interface compromises that WebForms seems to impose on all by the most heavily customised applications. Also, we wanted friendly URIs and we wanted a better separation of front-end and back-end development than that offered by WebForms (we settled on an XML / XSLT architecture).
In my opinion, WebForms in fact offer a much poorer method of interacting with the user specifically due to the use of ViewState, PostBacks, etc etc that abstract the actual mechanics of HTTP from the developer - this gives them less latitude in how they allow users to interact with the system. The classic example is that because WebForms pages are almost always the result of a POST, if the user attempts to refresh the page, the user gets a nasty warning message from the browser. The pattern in the traditional web development world for dealing with this has always been to include a 302 Redirect directive in the HTTP Response, thus sticking to the original HTTP paradigm of GETs being for retrieving data, and POSTs being for sending data. Other, similar problems exist such as the inability to have two forms on a page (for example a login form to a website on a different server).
That said, for RAD, WebForms are brilliant. I'm currently developing the admin application for a webapp we've developed using our custom MVC framework, and I'm flying through since all I need is to display the contents of a load of database tables, and in some cases allow the user to edit them, in various different ways.
I think that if we need to convince ourselves that MS are going to continue to support WebForms - just think of all the ex-Windows developers. These are the people that WebForms was originally developed for, and they're not going away. Corporate developers will be your saviour if you're a WebForms fan.