I am after recommendations for a framework (or project template) for rapid application development using C# on the back-end. It must support the following:
User login/authentication
SPA
Responsive client
Easy to understand client and server (not a steep learning curve like AngularJS)
Clean/uncluttered project structure (both client and server). Some OOTB ASP.Net project templates are very cluttered (eg the the VS2012/2013 SPA MVC/Knockout/BackBone template) - maybe I could be convinced, but just looking at a new project it puts me off instantly.
Easy DB access.
Flexibility on the client (for custom functionality eg adding maps and other UI libraries like D3) - don't want a client framework that you have to wrangle to paint outside the lines.
Would appreciate any/all suggestions/opinions.
Thanks
Tim
Like anything in software, there are so many ways to do this. You are essentially asking for a complete system architecture. You could try to be more specific, but your question is going gather opinionated answers and this will probably end up getting closed.
But I'm bored and will throwin a couple of pennies before that happens:
C# most likely means you'll be going .NET on IIS (though maybe its docker on linux?? refer back to my first line above)
User login/authentication
If its IIS, you could be running Windows Auth, or if in an enterprise, Kerberos or Federation. Or if its going against social sites, maybe OAuth? This one depends on what authentication your users need and is really separate of the other areas below.
SPA / Responsive client / Easy to understand...
You listed some very popular frameworks (Angular/Knockout) used in modern SPAs. You may not like them but these are becoming industry standards. Responsive web is pretty much bootstrap or foundation. Though, angular material seems to be gaining popularity too.
Easy DB access.
Whats your definition of easy? Looking for an ORM? If so, Entity Framework is popular in .net apps. Or if you are more of an SQL person, maybe LINQ is easier. Many options here too.
Flexibility on the client ...
Though you may not like some of them, using popular frameworks means you get a lot of developer support behind it - and a lot more answers here on SO if you have problems. One man's sunset is another man's sunrise. What you consider difficult might be viewed as easy by another. Hard to say whats most flexible but going popular means you got more help.
Related
I know I´m late for this party.
Currently migrating form asp.net webforms to newer coding technologies and paradigms. Barely got started with asp.net mvc and now I´m noticing all this fuzz about mvc vs webapi. I'm an oldschool programmer and don´t really feel confortable with the "use both" approach, if there´s no need to. Please consider this:
My web projects focus on dynamic dashboards/admin sites to manage CRUD operations for tons of SQL records, generate reports on demand, statistics, etc.
No static websites at all (like info sites, portfolios and such).
Performance over UI design. Actually bootstrap basic UI is enough for me.
Pure ADO over entity framework, whenever possible.
Any tip or guidence on what I should choose would be very much appreciated.
* Edit/Closing *
Hi again and thank you for your feedback.
After a lot of reading and experimentation I´ve decided to give a real hard tryout to asp.net webapi + angular.js, mostly because I want to leave the door open for multiplatform/device usage (not web only).
Also, I found a very interesting article/tutorial in https://superdevelopment.com/2013/12/16/building-rich-web-apps-jquery-vs-angular-js/
It may be a little old but I think it´s worth reading, specially this extract right here: "Angular.js and WebAPI is a new way to build rich interactive web applications that fully embraces what can be done with a Web browser, JavaScript and C# rather than relying on out-dated paradigms that complicate the process for all but simple use cases. If your users and clients are expecting an application in a web browser that behaves like a native app on their desktop or smart phone, then jQuery + ASP.NET MVC is not the most straightforward way to build it."
Anyway, thanks to all and I hope this info helps others in the programming community.
if your application is going to be consumed various type of devices then prefer web api.
if your application is like website or portal where user has very little interaction then go for MVC
I've been developing in ASP.NET for 1,5 years. (I used first Web Forms for a year and when I get a new project I decided to learn MVC) Now I am about changing job where they want me to develop in J2EE or SpringMVC. How long does it take to get practice in those (not to get pro just to reach a level to make good quality software)? I think that those web frameworks are very similar to the web frameworks of .NET I used.
Am I think right? Is there somebody who have changed from .NET to Java (or vice versa)?
I think of it as there are two main things you need to understand in order to build good quality software:
The general principles of the area you're working in
The specific details of the technology you're using at the time.
In the web-space, the principles of ASP.net and the concept of MVC is pretty similar to the concept of the SpringMVC. There are loads of Model-View-* type frameworks, which basically have the same concepts behind them.
You'll have the same set of concerns building an application in Java as you did in ASP.NET - Separate business logic from presentation, connect to a database, appropriate level of logging, security, error management, authentication, etc. etc.
The concepts you learned using ASP.NET you'll be able to re-use in the Java space.
The specifics of how you utilise them will be different (although often, surprisingly similar - compare nunit with junit, Hibernate with nHibernate). It'll take a little while to get to grips with how SpringMVC works and how it's configured, with how to build and deploy a Java project, with the particular structure of the libraries.
But in the end it's the same principles.
Also, particularly in the web space, all of the HTML, CSS, javascript, browser compatibility, user experience is identical. How you include that stuff in your project varies a little, but the actual markup that gets sent to the browser, and the challenges in making it right are exactly the same.
Doing something new like this will help too, because you'll see where the similarities are, and where the differences are. It might help highlight why they're similar.
It would be really good if you got on a project with some experienced Java people on it. They'll have the basics down and be able to structure it so that most of the big risks are managed, so you can get to grips with the technologies and differences to start off with.
Most really good developers can develop in several languages. I recommend you add Java to your list.
I've started to wondering whether ASP.NET Webforms/MVC even have a place in the web developers toolbox anymore... It seems that CMS systems like Umbraco have replaced the web developers job. Yes I know that those CMS systems are built with ASP.NET Webforms/MVC - however is there even any reason for learning those things if all you gonna do is to use a CMS system anyway? - Also I cant find any situation where a CMS system can be replaced by your own web application.
My question is therefore: Is there any reason for learning Webforms/MVC when using a CMS?
EDIT:
My question might be more like: When should I use a CMS, and when should I go and build my own web app?
The problem with CMS solutions, and I mean all CMS solutions (not just Umbraco, or other .NET solutions, but in any language) is that you will always pay a price for using them. You may gain more from the time-savings afforded by using the CMS, but there are trade-offs to consider:
You will sacrifice a great deal of flexibility
You could pay a significant performance penalty. Many CMSs load a large amount of modules and code to service every request, and much of this is not relevant to a particular page function. (though some CMSs are more monstrously heavy than others!)
The future of your project is tied to yet another vendor, and their own choices
Very often, you rule out the possibility of using other databases that might have better fit your customer's needs (Umbraco doesn't support PostgreSQL, Kentico only supports SQL Server)
Once you start using a CMS you will be tied into satisfying the architectural decisions and API of the CMS framework, and you could eventually be backed into a corner.
This can be particularly problematic if your 'site' is more of a web application than a pure content delivery site. In such cases it can make more sense to choose to build using the full flexibility of the web application framework, rather than risk getting backed into an architectural corner.
On the other hand, if you are building a web site that has potentially hundreds of pages, with a lot of user-contributed content and is much less of a web application, then often a CMS is the way to go, and makes a lot of sense. But remember, you now have two frameworks and two APIs to learn and manage (your platform's framework and the CMS framework).
Writing a CMS is like invading Afghanistan.
Everybody gets a turn but nobody wins.
I don't think that Stack Overflow could have been built with a CMS. Does that answer your question? =)
Update
To answer your updated question.
If you want a regular corporation web containing news, articles, forum etc: Go ahead and use a CMS.
If you need to build a more custom web site like stackoverflow, a web interface for a system or anything like that: Built it using MVC etc.
I personally use a CMS for our corparate website and a MVC framework to build user and administration interfaces for our products.
Not every problem needs a CMS. In the same way not every problem needs a bespoke MVC/webforms website. It depends on what your requirements are. You pick the technology to solve the problem.
Build vs buy is the hardest decision to make. As a developer build always looks best. You can do better than that pile of carp they want to buy. Nevermind that you're reinventing the wheel, axel, cart, etc. To users/management buy always looks best. They don't have to think to hard about what they want and can have it now, not 3 months later after you write it. They forget it'll cost the same again to customise & make it impossible to upgrade.
I'll stop ranting now.
Umbraco is a pretty bare minimum CMS. To customize it (e.g. Version 7+) you'll need to know Heavy MVC, JSON, XML, Sql, etc.
In fact a Site built on Umbraco 7+ is entirely based on MVC views you set yourself and assign to SurfaceControllers (which are MVC controllers) and all you are really getting is the ability for users to edit things about your pages and have Umbraco manage it for you in a DB.
In short you still need experienced web developers to build a site on Umbraco, they just save a lot of time by not having to build the entire backend from scratch.
You use Umbraco to organize Document Types that define what Templates (MVC Views) are used for rendering different types of documetns (e.g. Web Pages) and then you built the template from the ground up with 100% control over the HTML, Css, and Javascript that get's output.
Imo Umbraco is more of a Framework like Django than a complete CMS.
Sure you can build a site in Umbraco and not customize anything, but it would be a pretty cheesey site.
The whole point to Umbraco is to give skilled .Net Developers a good platform for building a site on top of it, but they still have to build it.
Now sharepoint would be more of a complete CMS out of the box that you can do a lot with, but let's see a few problems with SharePoint...
Resource Heavy, eats 50+ Gig's to install
Eats 16 GB of ram just to boot it up (Sharepoint 2013)
Requires Sql Server 2008 R2 or equivalent (enterprise license, $$ chaching)
Requires Windows Server ($$chaching)
It's a monster basically, if all you need is a user editable blod platform... man what a waste of money. Foundation is free, but doesn't include things like the Blog Site Template, so you buy a server enterprise license ($$ big cachinge, 40,000$+ in some scenarios...)
Agreed. A CMS like Umbraco provides a (very) good out-of-the-box solution for the most basic applications. Any sort of specialized purpose is going to require additional programming knowledge. Anymore, though, and your major, if not primary need is going to be a good understanding of the business need. I think we're getting away from building the Legos themselves and on to building the neat toys with the Legos. Cheers!
A CMS (or similar application framework) will provide you with a lot of functionality out of the box, and many of them also have a good library of plug-ins. But you'll still need to write WebForms/MVC code if you want to add any custom features.
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
Our team is divided on this and I wanted to get some third-party opinions.
We are building an application and cannot decide if we want to use .Net WPF Desktop Application with a WCF server, or ASP.Net web app using jQuery. I thought I'd ask the question here, with some specs, and see what the pros/cons of using either side would be. I have my own favorite and feel I am biased.
Ideally we want to build the initial release of the software as fast as we can, then slow down and take time to build in the additional features/components we want later on. Above all we want the software to be fast. Users go through records all day long and delays in loading records or refreshing screens kills their productivity.
Application Details:
I'm estimating around 100 different screens for initial version, with plans for a lot of additional screens being added on later after the initial release.
We are looking to use two-way communication for reminder and event systems
Currently has to support around 100 users, although we've been told to allow for growth up to 500 users
We have multiple locations
Items to consider (maybe not initially in some cases but in future releases):
Room for additional components to be added after initial release (there are a lot of of these... perhaps work here than the initial application)
Keyboard navigation
Performance is a must
Production Speed to initial version
Low maintenance overhead
Future support
Softphone/Scanner integration
Our Developers:
We have 1 programmer who has been learning WPF the past few months and was the one who suggested we use WPF for this.
We have a 2nd programmer who is familiar with ASP.Net and who may help with the project in the future, although he will not be working on it much up until the initial release since his time is spent maintaining our current software.
There is me, who has worked with both and am comfortable in either
We have an outside company doing the project management, and they are an ASP.Net company.
We plan on hiring 1-2 others, however we need to know what direction we are going in first
Environment:
General users are on Windows 2003 server with Terminal Services. They connect using WYSE thin-clients over an RDP connection. Admin staff has their own PCs with XP or higher. Users are allowed to specify their own resolution although they are limited to using IE as the web browser.
Other locations connects to our network over a MPLS connection
Based on that, what would you choose and why?
I am especially interested in hearing from developers who have experience with both ASP.Net and WPf.
Reasons to choose WPF:
Much faster and easier development than ASP.NET and jQuery
Much easier to implement quick incremental background loading of data
Much easier to implement client-side caching of commonly used data (important for remote offices)
More efficient data transfer from server (can use advanced WCF features unavailable to web browser)
Keyboard navigation better, since you can easily define shortcuts, etc, and not be limited by browser
Maintenance overhead much better using MVVM pattern
Softphone integration easy
Reasons to choose ASP.NET and jQuery:
None that I can see
In your scenario I would definitely choose WPF.
First of all, I would sit down and write the business requirements and specifications. It really doesn't matter what tech you use - proper planning will affect your project timeline more than technology choice. This is especially true for an in-house custom built app.
As far as development, I would take the requirements and lay out the backend functionality. I would actually implement the backend in WCF, regardless of the client technology - that way you could use best of both worlds if needed (for example for phone integration you could write a stand-alone WPF app). ASP.NET with jQuery can easily use WCF services (JSON or XML version) together with desktop client.
As far as development of the client forms, this highly depends on developers experience and your future plans. I am not going to go into advantages/disadvantages of developing web software here - there are a ton of articles in the last 10 years about cloud/web based software (for example salesforce). I would rather concentrate on deliverables - what is your team most comfortable with today and in the future. There's a huge difference between WPF and web development, from development standpoint, and it requires completely different experience.
Why not consider a hybrid solution - Silverlight
With Silverlight you get most of the goodness and statefullness of WPF (with almost exactly the same XAML and code), plus you get the deployment characteristics of ASP.NET
Many people consider Silverlight the next step after ASP.NET/AJAX, and it would definitely deliver all of the benefits of WPF relevant to your scenario.
WPF is the way to go, without a doubt. I agree with all that #Ray Burns has said.
Because:
You will get a richer, slicker, faster application.
It will be easier to build1.
Softphone/Scanner (i.e. hardware) integration is going to require browser plugins etc. and this can be a nightmare with a browser based application.
Keyboard navigation is still better with native applications.
IME Maintenance is easier with WPF applications.
Definitely use WCF to provide the backend via The Entity Framework, see The Entity Framework In Layered Architectures. You can do have a better integration with the backend in a native application because it can be called inline - no need for callbacks or ajax. I've built components for WPF that are linked via EF to the business logic to provide aware controls for simple stuff like validation. It's stunningly good to drop a customer name field onto a form and it just works.
To add additional components you need to build it with a proper well thought out plugin architecture. This is the same in both environments. I've got some thoughts on this I jotted down in my journal entitled Designing a plugin architecture for an application
When building a WPF application you will be writing in one language (e.g. C#) + markup (XAML). When building asp.net you endup with two languages + markup, as you always have to code some Javascript.
So, based on your requirements it has be to WPF / WCF (EF). A web based application will be a lot more work, more complexity, and not be as nice.
About 12 months ago I was fortunate enough to be given a free hand to choose the technology for a new application. I spent almost a month evaluating all of the options and came to the conclusion that it had to be C#, WPF, Entity Framework. After writing the application I can confirm that it was the right choice...
1. It will still be easier even if your programmers have to learn WPF first. WPF is much better thought out, great and lovely. very lovely. It just works right.
Hi
I think The question at issue is Windows-application or Web application(WPF for win-app VS asp for web-app), Which one is better for you and your project?. In this case your platform is network and your program must work on the net. so for this usage Web-app is better but there are a lot points existing which can make decisions hard. Network platform has great challenge.(according to my personal experience)
Working with web-app by asp.net is nearly hard. you must try to handle many thing's for web-app(request time, session management, even poor UI in comparison to WPF, j-query, etc ). Remember this is not as easy as simple web site.
But win-app is good for network with this condition: "local network"(mpls is almost the same). Absolutely developing win-app is easier than web-app ("At least number of users expert in net-program developing"). for this case WPF has many good things(UI , command, etc) also has many challenging point(like multi-threading and lack of expert developer in this field ) . I'm rather with wpf than asp but decisions is yours
And chalk point to good thing Silverlight but if you want to use this you must look at prism framework : http://compositewpf.codeplex.com/
I have recently developed a project separately with asp and silverlight(prism framework). developing silver-light version is too hard and takes more time than asp.net version but at the end SL-ver have great look nothing else!
Burns pointed to good issues about wpf. also consider Artemiy's post. your environment conditions is same for both of them. WPF/ASP can work with scanner and soft-phone cuz the base of both is on C# and .net library
Finally what ever your decisions is you must hire advance developer at least develop one business-app for the network platform.
Is your app a desktop app or web app.
If Desktop wpf is best.
If web based asp.net is best.
Don't front load your development with your get it up quick scenario. That never works well and results in a sloppy deployment. Take your time, cover all the steps (Business Requirements, System Design, Program Design, Code, TEST and TEST some more, Deployment)
Some points to be made for ASP.NET:
The pool of ASP.NET developers is much larger then the pool of WPF developers.
Which means you can probably find qualified ASP.NET developers easier.
ASP.NET is probably more future proof, chances of WPF getting large changes and being hard to port to later versions is probably larger.
Also keep in mind that the focus of MS seems to be on Silverlight so there might be a consolidation down the road which makes WPF obsolete.
More mature eco system of ASP.NET makes for more out of the box solutions to use to solve problems.
With multiple locations you might be able to skip a few layers and go directly to a website?
We have a large code base in MFC and VB. A few applications are in .NET. All these applications interoperate with each other on the user's machine and also connect with Unix servers via sockets.
Recently we have started discussing a re-write of our applications and possibility of moving a lot of these desktop applications to web (they would run in intranet). A straight forward way is rewritting them in one of the .NET technologies. But a suggestion about using Google Web tookit has popped up and the argument is that it would help creating applications that would run in a browser on both desktop and mobile devices.
One of the key problem that I see is that GWT is a large abstraction over Javascript. This will require the team to learn GWT, Javascript, IDEs etc as their experience has been primarily Microsoft technologies and not Java. It would be easier for them to learn .NET technologies instead of GWT.
I do not have a depth of GWT and its drawback pittfalls and do not know about a parallel Microsoft Technology that I should investigate.
So I would appreciate if people here can share their views or experiences using GWT or equivalent Microsoft technology.
Questions like this are subjective, so you wont get one straight answer. Are you rewriting the unix/socket backend as well? Or do you intend to put a web service wrapper in front of the sockets because without this I cant see a web / internet solution working.
For my money if you are a .net/microsoft house then a MS technology is the way to go. MS is currently backing jQuery which is a client side javascript framework, but there are others like extjs. If you stick with MS and a server side solution then ASP.NET MVC is currently gaining a lot of traction. MVC and jQuery work well together imho.
If you set up a REST based web service layer for your backend it means you can even get away with flat html front ends powered by any javascript framework without needed a server side web rendering technology at all. For REST you can look at .NET WCF if you stick with MS tech.
Given that you've been working with MFC and VB, .NET is going to be a new world to you as well. At least with Microsoft you'll have strong development tools and learning resources that you'll need. Not so sure that will be the case with GWT.
But also, if one of your developers wins the lottery and leaves the company, you'll have fewer problems finding another MS developer to replace him.
Given you guys are a Microsoft development shop, I'd stick with the Microsoft stack (unless your developers really want to learn something new - in my experience that's rarely the case).
Anyway, I thought I'd bring up that Microsoft had an "embraced and extended" version of GWT called Volta that they release 2-3 years ago. The idea is that it takes C# as its source file, and compiles that to Javascript.
I suspect the project is dead (I can't seem to find a whole lot of information about it), but you may want to verify that. I brought it up because you guys seemed like a Microsoft shop who's interested in GWT.
Based on your provided information I think it is better to use fromMicrosoft Technologies instead of Google Technologies.
This will reduce Cost (include Time to learn and also the budget and etc)
on the other hand, Silverlight goes on the windows phone mobiles with (WinMo7) so your application will run as the same in Cellphones too. So my sugesstion is to use Microsofts Technologies.