As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As a web developer I've discovered the joys of working with KnockoutJS lately but when it comes to working with the server I'm pretty much left on my own. I've considered BreezeJS and JayData for their CRUD capabilities and batch operations but I'm still not sure on which one suits me best.
I'm focused on ASP.NET MVC development with EF right now but I might switch to other platforms later and so I'd prefer not to be restricted to one particular framework. In this respect JayData offers a number of providers over BreezeJS like OData, webSQL, IndexedDB, localStore, Facebook and YQL which is almost overwhelming. BreezeJS does support OData however but only for consumption.
But how about ease of use, documentation and other crucial features which I might not have thought of?
Thanks for your help in helping me choose between them.
I'm member of JayData dev team, but I've tried Breeze, too.
Comparing them by the easy of use would be subjective, it depends on your taste. The intention of these libraries are the same: protect the developer from implementing protocol and concentrate on data management. But JayData isn't just a ORM library, but a unified data management paradigm and tool, which can be used on the server-side to build your own PaaS/BaaS.
As JayData was published in May 2012 with the provider-model, we had more time to implement more data providers (you missed the MongoDB on server-side and WebAPI, which will be released in few days) and support many developer platforms. I would mention the TypeScript support and the online-offline capability thanks to the unified API, which is important if you want to use the library now.
Breeze has also nice features on the roadmap and I'm sure you it will be a useful library in general, not just for consuming WebAPI services in a comfortable way.
The documentations is more or less the same, both team offer enterprise and community support.
If you only want to access WebAPI from JavaScript, I would pick the library depending on my prefered UI library/templating engine:
Breeze: Knockout, Angular, Backbone (Hopefully Breeze guys will update this with insider news)
JayData: Knockout (with dynamic queries), Angular (tutorial on the way), Handlebars, Sencha (read-only), KendoUI (comes in few days).
Both dev teams are helpful and listening to the tags, so you can ask how could these libraries solve the business problem or meet the technical requirements of your project.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have a large web application idea that I would like to work on, which will require secure database interactions, file creation and editing abilities, speed, and output html. It needs to be able to run on a webhost, not a self-run server. What would be the best programming language to use to create it? I am not looking for 'easiest', I am looking for the most useful for the type of web application I wish to develop.
EDIT:
It needs to be able to run on linux.
My pick would be ASP. NET MVC platform with Razor in-line syntax and C# for your code.
.NET ticks all your boxes, plus it has a humongous community, lots of help resources, tutorials etc. online; probably the best coding tool out there (Visual Studio 2010), easy to integrate with cutting-edge stuff like html5, jQuery, CSS3, AJAX etc.
ASP.NET is Microsoft technology, hence you will need to develop on Windows (anything from XP and above will do). C# uses similar syntax to JAVA. Razor is new and fairly easy to use. .NET works very well with most databases and you can even manage both your code and database in the same tool (Visual Studio) depending on which DBMS you'll go for.
And I guess the biggest argument, as Matteo Mosca pointed out is that this very site was built using ASP .NET MVC and, in my opinion, it does its job pretty well.
Please define "webhost". For a lot of people, that means "PHP hoster", and that sort of limits your choice of languages to 1.
For a large webapp, I would definitely take something that runs on the JVM (assuming that your definition of "webhost" includes some shop that accepts .war files for hosting - I usually self-host on virtual machines and run the Play Framework because it is so much easier). On the JVM, you have a choice of frameworks and languages - and again check out Play - and here it starts depending on language skills, specific needs, etcetera. Scala would, for a large app, definitely be on my shortlist these days.
Note that I say "JVM", not "Java". I think the JVM ecosystem rocks - you will probably find a site that takes the standard .war file format to host, if you need a library it is usually there, performance is top-of-the-line. Java as a programming language is so-so, but luckily there is choice these days.
Also, a lot depends on your skills, your preferences, etcetera. I'd say that Python, Perl, Ruby, C# all are very viable languages to build large websites. What development languages do you prefer? At the end of the day, that's a big factor in speed and ease of developement...
I personally would recommend a good structured project (n-layer approach, use of an ORM, etc) under .net 4.0, with the goodness of C# and the Mvc framework (version 3) for the UI part.
If you had bad experiences with .net web forms and you think that sucks, you're right. But the MVC framework is something else, built on the RoR approach.
That's just what I'd use anyway. Consider the power of the features of C# 4.0 (dynamic, linq, generics, etc), the fact that you will be using Visual Studio (which is commonly recognised as the best development ide around) and the great number of free components that are now available, and recently even easy to obtain and use thanks to NuGet package manager.
To give you a great example of a site made with asp.net Mvc - you are on such site right now. Stack Overflow and all the stack exchange sites are built on Asp.net Mvc, if I remember correctly. If not, somebody correct this.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I was looking for some current opinions on WPF based on their 4.0 release.
We are trying to decide if we want a Desktop application with a WCF server, or if we want an ASP.Net web app. I would really like to do it in WPF, however some major concerns have come up that I am not sure if WPF can handle. I have looked around online and a lot of WPF reviews are based on the 3.5 version, so I was looking for some current opinions.
What sort of Support is out there for it? Microsoft support and Community? Is WPF a dying technology or a growing one?
It is harder to find WPF programmers. Is this always going to be the case?
What is the performance like for terminal services? The majority of our users login using WYSE thin-clients to a Windows 2003 terminal server. Each server normally has between 10 and 30 people on it on any given day. Most of our TS users only need basic view/insert/update abilities and our admin staff needs the more advanced features and reporting. The admin users all have XP machines with SP2 or higher.
What other concerns should I have about WPF?
It seems the underlying concern here is whether or not WPF is a mature enough technology for serious desktop application development. The answer there is IMHO certainly yes and the proof I offer is Visual Studio 2010. It is written in WPF, is a major desktop application and has to meet the criteria laid out in your question.
To attempt to head off the 2010 is slow + buggy argument. Yes, 2010 is not a perfect product and has bugs. The vast majority of those problems are not purely a WPF issue but instead are related to legacy code, managed native interop or just interesting interactions between old and new technology.
To answer some of the non-technical questions with hand wavy answers ...
Yes today it's probably harder to find WPF programmers than say WinForm programmers. WPF is a newer technology and hence likely won't have as many developers. Will this be true in the future will only be decided in the future :)
I feel like there is great support for WPF (see the WPF tag on this site for an example). When I started doing WPF work for the 2010 release the vast majority of the questions I had were already answered on this site or in blog tutorials.
#1 - I've done projects with WPF. There is quite a bit of information out there. Microsoft seems to be investing more in Silverlight at the moment, but I suspect that WPF and Silverlight will be merged in the coming years. WPF/Silverlight/XAML will be Microsoft's way of building desktop apps for the foreseeable future.
#2 - Developers with good WPF (or Silverlight) skills are hard to find, though not impossible. WPF/Silverlight definitely has a steep learning curve.
#3 - There have been problems with WPF apps running on terminal server because WPF runs on top of DirectX. I would definitely try running a WPF app on your Windows Server 2003 terminal server to see how it behaves. My biggest concern would be that Microsoft would likely be investing in any WPF-related fixes for Server 2008 TS and I'm not sure they would necessarily port those to Server 2003. As for a good test app, I would grab something like the WPF photo viewer demo (http://msdn.microsoft.com/en-us/library/ms771331%28VS.90%29.aspx). Something reasonably graphically intensive to stress TS.
#4 - Personally #3 is the biggest concern IMHO. If you can't run on Windows Server 2003 TS, the other questions are moot.
Concern #1: What sort of Support
So far, it's growing and growing well. The IDE support is finally decent as of VS2010, and it appears as though MS is going to be pushing this for a good amount of time. There are lost of examples from MS and the community.
Concern #2: It is harder to find WPF programmers.
Well, it depends on how crazy you want to get with your UI. If you want the latest, greatest whiz bang 3D animations and multiple effects, it might be difficult to find someone off the street with all of those skills that you can afford. However, if you're banging out a relatively simple UI, many experienced developers can quickly grow into this role.
Concern #3: What is the performance like for terminal services?
That depends on how much animation and other whiz bang features you want to add. If there is lots happening on the screen, it will take more bandwidth. Once again, a simple interface should have no problems.
Concern #4: What other concerns should I have about WPF?
Hard to say!
There is always a risk that a technology will become obsolete. That's just the way it is. And there's no way to know for sure.
Here is a possible scenario: WPF is being overshadowed by Silverlight, since everyone wants to "do it on the web." You decide to develop your application in Silverlight (even though it's only a subset of WPF's feature set) and get blindsided by HTML 5, which takes over the world because now you can do everything in the browser without a plugin. Even Flash becomes obsolete.
Will it happen? Who knows?
People are still quite happily making Winforms applications, arguably an obsolete technology. Are they worried about obsolescence? Probably not.
As far as I know, Microsoft actively and enthusiastically supports this technology. If you are concerned about performance and other issues, the best way to find out if it meets your needs is to build a prototype.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
If you were starting a new web development project would you use ASP.Net MVC 2 or Ruby on Rails?
I have recently invested some time in to learning Ruby on Rails because I wanted to learn a solid web development framework. Then I took a new job where I will be using ASP.Net MVC 2.
I know this question is very subjective, but I am planning to write some websites on my own, outside of work, and I would like to get some opinions from others.
Professionally, I'd go with what my team knows best (in my case, MVC and the .Net stack). Since if you have a team with years of experience on a framework, a new app for a production system is not the place to learn new things.
Personally, I'd start by determining where I wanted to take my own learning plan next (I code in both Ruby and .Net, and have personal sites in MVC and Rails). For example, when I wanted to do some personal development in BDD, Jquery, etc. I decided to do my site in MVC since I didn't want to add another learning opportunity at the same time. Now, as I'm looking to build another learning site, I want to play with Cucumber, RSpec, and rails as a learning exercise (and build a nifty site to boot).
Lastly, if I was building a new site with the intent of selling a product or turning a profit, I would objectively figure out which I felt I could get out the door in a shippable state in the shortest time possible. Today, that would be an MVC site. Tomorrow, it might be Rails since I'm on a Ruby studying binge right now.
So to answer, I'd say it depends on your goals (business, learning, profit) and how this site fits either into your professional or entrepreneurial plans or your personal development plan.
The .NET skills you'll acquire working with ASP.NET are applicable across the entire development spectrum; not just web development. Want to write desktop apps? XBOX games? Parallel processing services? Linux or Android apps? You can do all of that with C#/.NET.
I've heard good things about Ruby. I use a variety of languages for different tasks -physicists seem to love SCHEME which has been causing my therapist nightmares as of late - but my web projects are exclusively in .NET.
The best way to become proficient with a new language is to immerse yourself in it, and write something FUN. If you want to get up to speed on the new job as quickly as possible, write something you're interested in using the tools they prefer. ASP.NET MVC is more complex than Ruby, but it's also incredibly powerful once you pass that "Ah ha!" bump in the learning curve.
don't take a poll on stack overflow, use whatever interests you. work is for paying the bills, your personal projects should be for expanding your mind (and having fun)
Since you'll be working with ASP.NET MVC, if I were you I would learn Ruby on Rails on your personal projects. Learning both will make you a stronger programmer because you can see the same solution from multiple perspectives.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Anyone have any experience evaluating BlazeDS and GraniteDS? I'm curious about which is better at integrating with Spring/Hibernate.
If you are just looking for simple RPC and messaging, I would go with Blaze. The implementations are more mature and better proven, especially with respect to messaging. The messaging in Granite is based on Comet and still pretty new from what I remember. More details below...
Blaze DS is basically a stack that includes RPC and some simple messaging services over HTTP. Integration with Spring is achieved easily using the SpringFactory implementation of FlexFactory: just google the class name and you'll find the code. It doesn't offer any additional support for things Hibernate-related.
Granite DS is growing rapidly in terms of features. It competes more with LCDS than Blaze DS. It includes the ability to parse Hibernate object graphs and deal with lazy proxies in a clean fashion. They also have a tool called "Tide" that creates an analog of a Session in the Flex client to ensure uniqueness of entities. They also have explicit support for services exposed via Spring, EJB3 and Seam. Granite also has a utility for generating AS3 classes from your Java classes (although this not hard to write yourself if you want to).
I worked with Granite about a year ago and had some problems getting it properly parse object graphs; the Flash Player would throw some nasty low-level exceptions. My guess is that the documentation and implementation have matured since so that these are no longer issues. However, I'm still a bit hesitant to recommend it since I ran into issues and switching to Blaze immediately resolved them with no trouble at all.
A few side notes on Cliff's comments:
GraniteDS was created late 2006, about one year before BlazeDS. It is widely used in demanding production environments and could be at least considered as mature and proven than BlazeDS.
GraniteDS messaging was introduced in the 1.0 release (late 2007, few weeks after the first BlazeDS release), it is now very mature and proven as well in demanding production environments.
The Flash player exceptions encountered by Cliff are generally caused by failing to compile all generated AS3 classes in the SWF. It is only a matter of using a Flex compiler option that forces the inclusion of these missing classes, which are part of the data graph model and required at deserialization time but not explicitly used in the MXML/AS3 code.
Most of the GraniteDS users are coming from BlazeDS/LCDS because these two frameworks are not dealing correctly with complex data models (no or faulty lazy-loading support, bad transaction isolation, etc.)
So, IMHO, unless you are developing a small application with a rather trivial data model, you should go to GraniteDS.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am currently looking at a distributed cache solution.
If money was not an issue, which would you recommend?
www.scaleoutsoftware.com
ncache
memcacheddotnet
MS Velocity
Out of your selection I've only ever attempted to use memcached, and even then it wasn't the C#/.NET libraries.
However memcached technology is fairly well proven, just look at the sites that use it:
...The system is used by several very large, well-known sites including YouTube, LiveJournal, Slashdot, Wikipedia, SourceForge, ShowClix, GameFAQs, Facebook, Digg, Twitter, Fotolog, BoardGameGeek, NYTimes.com, deviantART, Jamendo, Kayak, VxV, ThePirateBay and Netlog.
I don't really see a reason to look at the other solution's.
Good Luck,
Brian G.
One thing that people typically forget when evaluating solutions is dedicated support.
If you go with memcached then you'll get none, because you're using completely open source software that is not backed by any vendor. Yes, the core platform is well tested by virtue of age, but the C# client libraries are probably much less so. And yes, you'll probably get some help on forums and the like, but there is no guarantee responses will be fast, and no guarantee you'll get any responses at all.
I don't know what the support for NCache or the ScaleOut cache is like, but it's something that's worth finding out before choosing them. I've dealt with many companies for support over the last few years and the support is often outsourced to people who don't even work at the company (with no chance of getting to the people who do) and this means no chance of getting quality of timely support. On the other hand I've also dealt with companies who'll escalate serious issues to the right people, fix important issues very fast, and ship you a personal patch.
One of those companies is Microsoft, which is one of the reasons that we use their software as our platform. If you have a production issue, then you can rely on their support. So my inclination would be to go with Velocity largely on this basis.
Possible the most important thing though, whichever cache you choose, is to abstract it behind your own interface (e.g. ICache) which will allow you to evaluate a number of them without holding up the rest of the development process. This means that even if your initial decision turns out not to work for you, you can switch it without breaking much of the application.
(Note: I'm assuming here that all caches have sufficient features to support what you need from them, and that all caches have sufficient and broadly similar performance. This may not be a valid assumption, in which case you'll need to provide more detail in your question as to why it isn't).
You could also add Oracle Coherence to your list. It has both .NET and Java APIs.
From microsoft : App fabric
Commerical : NCache
Open source : RIAK
We tried a couple in the end we use the SQL session provider for asp.net/mvc yes there is the overhead of the connection to the DB but our DB server is very fast and the web farm has loads of capacity so not an issue.
Very interested in RIAK has .net client and used by Yahoo - can be scaled to many manu server