I am a little bit puzzled about something. I am creating a ASP.NET MVC eCommerce application and currently I have written all the back end in ASP.NET MVC.
I was thinking if its better to write all the management in WPF instead of HTML, as its probably even less prone to be exploited by hackers.
I am a Windows user so I am not really bothered about using Linux/Mac at the moment so I am quite aware that having all the back-end written in HTML will allow users to have access to the admin area using other OS.
I would like to see what are the advantages and disadvantages of having WPF to manage the content of the website as its probably much easier to develop and manage (think about Live Writer).
4-5 years ago a desktop app would probably be what you wanted to use. These days the browser is the OS and if its not on the web people just won't use it. On the web you get simplified deployment and anybody can access it anywhere. With WPF you get... shinier gradients?
"I was thinking if its better to write all the management in WPF instead of HTML, as its probably even less prone to be exploited by hackers."
An intranet website would be just as secure as a internal wpf application.
You can have combine both and make it in Silverlight (and gain most advantages and disadvantages of both - you will have a rich UI, but at cost of platform independence).
I don't think it is a very good solution for eCommerce backend though, HTML + JS can offer you all the flexibility you need and with JS libraries like jQuery is writing impressive UIs quite easy.
I personally hate platform-dependent website backends (I can recall one CMS that requiread IE 6 to work, it was total pain in the *** :) ).
Some considerations:
1) Is your team primarily made of web developers? Does it make sense for them all to learn/use WPF development?
2) How will you deploy updates to the WPF app? One thing I like about web-based internal tools is you don't have to worry about versioning/deployment so much.
3) How will you authenticate users? For an internal application that uses domain based security, I think a web app is much easier as IIS and the browser will take care of authentication/login session.
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 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.
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.
We need to build an administration portal website to support our client/server application. Since we're a .Net shop the obvious traditional way would be to do that in ASP.Net. But Silverlight 2 will be coming out of beta a good while before our release date. Should we consider building the whole website in silverlight instead, with a supporting WCF backend?
The main function of the portal will be: users, groups and permissions configuration; user profile settings configuration; file upload and download for files needed to support the application.
I think the main reason for taking this approach would be that we have good experience with WPF and WCF, but little experience in ASP.Net. Either way we would have to learn ASP.Net or Silverlight, and learning Silverlight seems a more natural extension of our current skills.
Are there any big no-nos from the experience of StackOverflowers? What are the big positives?
I would recommend against building a pure Silverlight site.
Silverlight suffers from the same issues as Flash does: Unintuitive Bookmarking, issues with printing, accessibility issues, not working back buttons and so on.
Also, you would require your users to have Silverlight installed or at least to have the ability to install it.
In controlled environements (eg. in large companies or health care) or on mobile devices, this might not be the case.
I would definitely go for a full Silverlight application, specially if you have good experience from WPF. You will be able to reuse your knowledge from WPF, and should be able to pick up Silverlight fairly quickly. I've been working with Silverlight since Beta 1, and the current Beta 2 is of solid quality. I guess it's safe to assume that a RTW version is just around the corner.
Pilf has some valid point, specially around printing. For that I would probably use SQL Reporting Services, or some other reporting framework, on the server side, and then pop up a new window with printable reports. For linking and bookmarking the issues are no different than any other AJAX application. I did a blog post today about how to provide deep linking and back-forward navigation in Silverlight.
Silverlight also has all the hooks needed for great accessibility support, as the UI Automation API from WPF is brought into Silverlight. I don't know if the screen reader vendors have caught up yet. The styling/template support in Silverlight makes it easy to provide high-contrast skins for visual impaired users if that is a concern.
Depends on your goals. If administration portal is part of application and will only be used from computers where your application is installed, there are plenty of advantages of going fully Silverlight - or even WPF.
But if you can see a scenario where it will be used either from random PC or by random person, fully functional HTML/Javascript version is absolutely necessary.
Some reasons are:
Most people don't have silverlight and you'll earn a good load of swearing if they have to download and install it. Some people who have it installed keep it disabled (together with flash and sometimes even images) to avoid distractions and speed up browsing.
When HTML site fails, user gets error page and reloads. When silverlight fails, it can hang or crash.
HTML is what is expected - both by users and web browsers: back and refresh buttons work as they should, hyperlinks and forms work as expected.
Slow internet is still very common, both in remote areas and mobile devices.
I agree with what everyone had said so far and I think this Flow Chart, which is aimed at Flash, also applies to Silverlight.
Source of Image
It sounds like your problem is that you need a rich-client admin application. Why not use click-once?
On the topic of remote andministrators, another poster stated that was an argument in favor of HTML if the admins were on a slow connection. I would argue that depending on the type of information, it may be more efficient to use Silverlight. If you have an ASP.NET datagrid populated with server side data binding, you can be downloading a ton of markup and viewstate data. Even if you're using an alrternative to DataGrid that's lighter on the ViewState, you will still have a lot of HTML to download.
In Silverlight, once you get the XAP down, which is probably going to be smaller than the corresponding HTML, the XAP is cached and so you shouldn't have that cost every time, and you'll just be retrieving the data itself.
For another example, let's say you have a bunch of dropdown lists on one of your forms which all have the same values in the list. In Silverlight, you can get these values once and bind them to all of the dorpdowns, in HTML you will have to repeat them each time.
This will get better with client side data binding in ASP.NET, which follows a very similar model to Silverlight and WPF for data binding.
Overall, I would also think that you would need to write less code for the Silverlight implementation which can increase productivity and reduce maintenace costs.
ASP all the way. You should only use silverlight/flash etc when text can't do what you want it to do - e.g. display video.
Using a plugin for your website makes it slow, and requires the user to have the plugin installed. Silverlight for instance rules out all Linux user. Also, since Silverlight is pretty new, there is no telling how committed Microsoft will be to keep the platform alive if it doesn't pick up soon.
I'd stick to plain old HTML with server side scripting.
Also, for public websites: Flash and Silverlight can't be indexed by any search engine, so good luck with writing tons of metadata if you want any visitors at all.
Silverlight is a good choice for an internal-facing portal, just as it would be for a public-facing portal if you've already evaluated your project and have decided to go forward with a web portal. You are free to integrate Silverlight components within an existing ASP.NET application (i.e. the "islands of richness") approach, but if you have the ability to build a new project from scratch, don't discount a completely Silverlight solution as a valid choice where you would have went with a traditional ASP.NET portal. Silverlight is RTW now, so if this decision is still on the table, you know you won't have to deal with breaking changes going forward.
There are some downsides with developing a site completely in Flash / Silverlight, but if those downsides won't matter to you or won't have an impact then there is nothing stopping you. Choose whatever tool you think meets your needs more fully. I wouldn't be put off creating a site purely in Silverlight based on the downsides, because it brings a lot more positives to the user experience.
The previous comments have dealt with most of the downsides of using Silverlight for a site like this and I agree. If you're determined to have rich-client style development and your audience is small (for admins only) then I'd probably recommend WPF over Silverlight as it currently provides a richer set of tools and controls.
If you stick with ASP.NET have you looked at Dynamic Data - it's ideal for building backend management sites with little effort.
I've seen "Silverlight only" websites at Microsoft and they are pretty impressive. But again, the demos were there to exploit the full potential of what Silverlight can do. The moment you need something different you may be out of luck. I don't see Silverlight like Flash except in the way they are installed/seen. But the Flash/ActionScript backend is really bad compared to what Visual Studio can offer with .NET
Ask yourself why would you like to use Silverlight? Fancy effects or programming model?