I realize this is a subjective question, but is MVCContrib dead? The NuGet package has had no updates since 2011, so normally I would consider a project like that dead and likely replaced by something else (i.e. something I should go find and use). I see there are infrequent commits, but having no NuGet package updates is strange.
But I can't find any alternatives for the basic requirement of wanting DRY links and redirects in MVC (i.e. using lambdas over strings for things like ActionLink and RedirectToAction). Has the Microsoft MVC team integrated these features in some hidden namespace that I don't realize? And if not, does anyone know why not? I would have liked to have seem the string-based methods deprecated by now...
So far I see, it is an active project as you can see on commit history. Probably it's not as an active as it was on early stages, it might be possible they think is enough with current features.
Also, take into account that there are nuget packages for every mvc version. For instance, latest one is for MVC 5 and publish date is on 2013-11-21
Related
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.
At the moment I am building a big project using:
ASP.Net MVC 4
jQuery (With some extra libraries)
Castle ActiveRecord (based on NHibernate)
Implemented users and roles using .Net Membership Provider
I built almost all the website, but some very relevant parts are missing still and I noticed that this CMS supports
ASP.Net MVC and NHibernate, and have almost all the features that I need already implemented.
The features that I still need to implement are:
Internal Search Engine
Comments
Version of content
Chat betwwen users
Users Profiles Page (Something like a very basic social network)
Forum
SEO
I don't know if is harder to use the CMS or if is better to add the features one by one manually.
I am worried about the time I spend learning and adapting to Orchard is the same time I would spent adding this
features manually.
Basically, the question is:
Should I move my solution to Orchard CMS or add everything manually ?
You can't just move your solution to Orchard, you could but i won't recommend it. Orchard is still MVC 3 at the base and that way most should work if you just move your solution including the database etc. But if you ask me, spending time to add the features manually is the way u should go.
In the Orchard Galery you can find existing many modules
Internal Search Engine
Lucene (Fully functional - Writen by the Orchard Team)
Comments
Already exists in the Orchard Core Module
Version of content
Already exists in the Orchard Framework functionalty
Users Profiles Page
Profile (Fully functional? Or at least good enough as example)
SEO
Several modules
Only 2 features u will have to write yourself
Chat between users
I can't find any example code for this, but I know Piotr Szmyd has tested SignalR inside a Orchard Module which, I think, will be usefull for a Chat module. Demo is here.
Forum
Nicholas Mayne made a start of a forum module which can be used as example or starting point, maybe you can help him extent it? Currently it's sort of a pre-alpha version :(
+1 to rfcdejon's answer. I ported my current project to Orchard after at 50-60% complete. I wish I had done it sooner due to the learning curve and time to integrate all the stuff I had already written, but overall it was the right choice.
If you have significant data already set up you should account for the extra time it will take to port that into Orchard. But if you are making an app from scratch with very little existing data that would make the switch to Orchard easier. Orchard is a great choice for anyone looking for a .NET CMS that supports MVC.
Some things to keep in mind:
Features you've already built will have to be converted into Orchard content types/parts in order to take advantage of things that come out of the box with Orchard, like search, comments, versioning, etc.
Orchard has its own users/roles system, so you might have to do some work to find a module for what you're already using, or override Orchard's user/membership system yourself.
Your entire app will have to become an Orchard app, and your existing MVC stuff will have to convert into an Orchard module. Existing data access code will have to be wrapped inside a using (new TransactionScope(TransactionScopeOption.Suppress)) {...}
Forums project has started but isn't done, so you will either be banking that it will finish in time for you to use it, or that you will be able to help get it working.
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.
Has Microsoft said anything in the past year about Sharepoint supporting MVC (in a nice, non-hacky way)?
I know Scott Gu said something on the subject, but that was just shy of 3 years ago (Feb 2008).
Are they still "looking at it" for the future? (3 years seems a long time to be "looking")
Did they decide against it? (the whole MVC thing is just a fad, it will die out...?)
Or have they been mute on the subject?
(We are about to embark on an enterprise level implementation of Sharepoint and I am worried that we are investing a lot of time and money into an old way of doing things.)
Note: I know that there are questions like this out there, but they seem to be about a year old, so I thought I would ask again.
Don't hold your breath for SharePoint to go MVC. SharePoint contains a lot of custom controls that would have to be rewritten completely, if they changed the underlying model. Changing from ASP.NET Web Forms to ASP.NET MVC would probably result in a whole different branch of SharePoint - think SharePoint MVC. And if Microsoft was to go that way, they would probably choose a different path for that solution, perhaps even backing the open source CMS Umbraco.
I personally believe that MVC is not a fad. It you care about what your html ends up looking like, then ASP.NET MVC is a great platform. And with the popularity of HTML 5 rising, I see the same thing happening for ASP.NET MVC.
It's a huge breaking change, so I'm ruling it out for SharePoint 2010, also because newer MVC Versions are .net 4.0 only and SharePoint 2010 is .net 3.5 and will highly unlikely go to 4.0, again because it's a huge breaking change.
I saw some hackish attempts, but getting even Routing to work with the Virtual Path Provider of Sharepoint...
I'd say: Wait for SharePoint 2014 or whatver the next Version will be.
I wouldn't worry too much about it. Treat it as a platform that you plug in to, so the way it works doesn't have a huge impact on your implementation apart from around web parts. If it goes MVC then everyone will have the same pain of moving their web parts from the current model to an MVC type rendering one so MS will have to provide some help in making the transition.
This link is about a year old but I thought the author's perspective on the choice between SharePoint (a platform) and ASP.NET MVC (a framework) was refreshing at the time. I've had experience with both and I've gotta say that I'd be hesitant to mix the two technologies right now.
The only thing I think is safe to say right now is that SharePoint is here to stay and ASP.NET MVC is gaining tremendous popularity / support and is unlikely to go away.
EDIT: There are also a number of comments in that link that might relate to your question.
Introduction:
Now I know this question could be very broad and it would be too hard to answer without me asking something specific. So All I ask is just some direction, or a brief high level explanation of a design, or maybe there is already some framework out there that could help me get started...I'm not sure.. I have never designed a plugin architecture before, so maybe there is some resource/example you could point me to on the web that would help me learn so that I may come up with my own solution.
Details of my question:
My intention is I would like to create a plug-in architecture for a new pet-project that I am building in ASP.NET MVC.
I would like to design it so that it has some sort of plug-in ability for all, or at least most, of the application's components.
The reason I would like to do this, is so that I may be able to do deployments with nearly zero down time. The idea is that when I want to deploy the latest version I would drop in the new DLLs into a specific folder, and the application would load up the new plug ins and that is it.
For exapmle, lets say I add a new "contacts" feature to my web application where users can search, add and delete contacts. I would like to be able to deploy that by way of plugins.
Is something like this even possible for Web Applications? Or am I just dreaming?
It's definitely possible.
You will need to define a pretty comprehensive interface that represents everything your plugins will have to do. You should approach it by differentiating what is "core" to your application, and where the extensibility points are. For example, where will the plugins be accessed? Will they be tabs on a page, or links in a sidebar? What properties does each plugin need to have in order to fit into the plugin container?
Generally, plugins are enumerated via reflection by looking for assemblies that implement the plugin interface.
Just for encouragement, we've done this with an enterprise product that provides a generic framework for "management" interfaces for web sites. Developers just need to drop in a plugin dll that builds specific property pages, and they show up in the management interface menu, all the navigation is taken care of, and their dll's just have to worry about their own domain logic.
There is always the dll-way where you define some interfaces that plugins follow.
But for web application, especially ASP.NET MVC, you need a controller, views and so. Probably these can be included in a dll file using prepared controller factory to handle that, but it would be hard to develop these plugins.
Some inspiration for code (or db) embedded content: Haacked about that
ASP.NET MVC version 2 will support areas, where you can put some parts of the application into different folders within the app. This way you can just upload some files and the app will recognize these new files. Read more there Haacked blog
PS: I found another person here on S.O. asking the same question as me:
Plug-in architecture for ASP.NET MVC It might be useful for someone researching the same topic.