This makes me even more bullish on Xamarin/Mono. As Miguel de Icaza of Xamarin tweeted this morning after this was announced: "Wow @scottgu announces that Microsoft open sourced the Entity Framework, Mono's Achilles heel"
I believe if you are building mobile clients and need to target more than one platform you should do your UI with the native APIs on each platform, but should use something like Mono to achieve as much code-reuse as possible for the lower layers of your app.
It is crazy how C# is one of the few languages you can actually use to develop both iPhone and Android apps (as well as WP, obviously). It's a great language- I just wish that a license for MonoTouch didn't cost $400.
Also, does anyone know how to develop for MonoTouch using Visual Studio? I want to like SharpDevelop but I just can't... and of course, VS doesn't run on OSX.
(I haven't tried SharpDevelop in over a year- it might be dramatically better these days, but I don't think so)
So you get Visual Studio, Intellisense, tools like Resharper, but you can't quite build, because of missing elements. The build process would be to swap over to the Mac side to build and simulate.
This will let you load MonoTouch projects is VS and compile but the compile is only for syntax checking, etc... You still have to do the actual binary build on a Mac. Still, with this you can use all the refactoring tools, plug-ins, Intellisense, etc... that VS has to offer.
The amazing thing to me is that they've been able to thrive simply by focusing on mobile... they dropped Moonlight on the floor even as MS-bound line-of-business devs everywhere found out that Silverlight is a dead end.
>
> Some of the other work I believe is a gold mine of technology,
> in particular our media pipeline, the rendering/layout code and
> the animation framework. Perhaps someone would find a use for
> that code in the future, we currently do not have plans to
> continue developing Moonlight.
>
> - Miguel de Icaza
>
The thing I want to do is essentially implement the repository pattern against the database. Keep all my models nice and simple with helpful extension methods, share the context and do the joins lazily in the service layer.
I have never been able to do it against MySQL and have it work, on Mono or .NET runtime.
Despite my usual complaints about Microsoft, I really appreciate the direction they've been heading with their adoption of open source for a growing number of their products.
ScottGu, Hanselman et al. really deserve a lot of credit for the big cultural changes they've caused to allow a lot of this.
Indeed, it's also great to see that they are starting to use more widely accepted open source licenses, which as the Apache License (as was also the case with ASP.NET MVC).
I think of it slightly differently - "I really appreciate the direction that Microsoft developer tools division has been heading with their adoption of open source for a growing number of their products.
They deserve big credit. But devs appreciate open source more than other consumers. it's hard to see how open source would work for, say, the parts of Microsoft that make Windows, Office or Xboxes.
Like it or not, the MS Windows division can therefore boss the dev tools division around (and have in Windows 8, effectively dictating the direction of .Net and WPF).
Its hard for me to say this in some ways, but of the bigcos, I'm most bullish on Microsoft. I might actually go stand in line (if there are any) for the Surface tablet and maybe even a Windows Phone 8 device.
They are (finally) making the right moves and doing it in a consistent and open way. Any Microsoft insiders know who is driving all this change? ScottGu? Steven Sinofsky?
Seems more like a desperation move to me. Microsoft have almost no presence in popular web apps or mobile. Almost no startups or established services use the Microsoft stack. Maybe they think that by open sourcing they will get a look by devs/shops that would never have considered them before.
I still think it's a long shot. The best development platform for .NET is Visual Studio and Windows. And the "cool startups" all use Mac OS or Linux.
.NET has been sold as an enterprise platform since the beginning. That's what it's thought of by most people, and I don't really see this changing anything. Windows Phone is way late to the party and isn't going to do anything significant in the market. Microsoft will continue to be primarily a platform for building enterprise-type CRUD apps.
Note: only their Azure + DEV arm is OSS happy - which is a result from making money with it on Azure.
Their Windows/WP/UI projects are violently closed source, almost all cross-platform Rich/UI initiatives have been killed since Sinofsky has taken back the helm. Personally they should do all C#/.NET devs a service and provide better integration/code-reuse with MonoDroid/MonoTouch, but as they don't see it in their best interest they're pushing for platform-lockin. Which is a strange play when you're hopelessly behind the incumbents.
This is starting to be a real problem for .NET devs now (since MS is losing their influence) as they become pawns in Microsoft's platform strategies, whilst we (C# devs) miss out on the most exciting platforms Microsoft doesn't want you to develop for, e.g: iOS/Android, NaCL, Unity3d, RaspPi, etc. We're just lucky Mono exists which runs on all these platforms.
That's no different from using HTML5+JavaScript against browser specific APIs or using CSS3 vendor prefixes. Calling external stuff from JavaScript (even if that external thing is Windows itself) is not new and it's not bad that it's not portable any more than writing XUL wasn't portable.
If there's no equivalent work around it's not portable - simple as that. Proprietary hooks and APIs aren't evil, but suggesting developing for Metro is "open" and portable is wrong.
Since you've mentioned it, Mozilla isn't touting to use XUL for "open" cross-browser apps - although XUL itself, unlike anything Metro, is open source and does run cross-platform. Mozilla is even deprecating the use of XUL for its new Firefox OS (Boot to Gecko) in favor of using pure HTML5 instead. Maybe MS can work together with Mozilla and come up with a common API?
>> And Boot to Gecko will no doubt use lots of Firefox OS specific stuff just as WebOS does.
Where did you hear that? everything I've heard is the exact opposite:
http://www.geek.com/articles/mobile/a-deep-dive-into-mozilla...
>> Everything is HTML5
>> The core to the Boot to Gecko project is the web. Everything you see — right down to the power icon and network status information — is generated by and displayed with HTML5. The icons for the apps, the apps themselves, and the notifications the apps generate… all HTML5. Even the Dialer and the Settings for the device are handled this way.
http://en.wikipedia.org/wiki/Firefox_OS
>> Firefox OS (formerly Boot to Gecko, B2G) is an open source operating system in development by Mozilla that aims to support HTML5 apps written using "open Web" technologies rather than platform-specific native APIs. The idea is essentially to have all user-accessible software running on the phone be a Web app that uses advanced HTML5 techniques and device APIs to access the phone's hardware directly via JavaScript.[2] It initially targets Android-compatible smartphones.
The difference is Firefox OS is building as much as they can (everything?) with HTML5, Whilst all Metro's advanced functionality is hidden behind proprietary APIs - The comparison of "open-ess" between the 2 is not even close.
What existing "HTML5 API" is going to give you network status and power icon info? Of course everything will be HTML5/JavaScript/CSS just like Chrome OS, but the fact remains that that functionality doesn't exist in the W3C specs as they are.
Checking out the Mozilla Docs at https://wiki.mozilla.org/WebAPI it appears that these "privileged" APIs are extensions, as they should be. For example, navigator.fm.antennaAvailable is to control the FM Radio.
And Boot to Gecko will no doubt use lots of Firefox OS specific stuff just as WebOS does. I'm not defending Windows 8, I'm just pointing out that it's reasonable to use a language (JavaScript) to call out to 3rd party APIs.
There are plenty of startups that have been successful on the .NET stack. The one that pops to mind first is Stack Overflow. .NET & XNA are pretty popular in indie games due to exposure to the xbox. There are many examples, but they don't tend to over lap much with the crowd here at HN.
>> In the process of getting rid of ASP.NET repeaters and instead uses the append string thing or response.write...
Even as a long time .NET developer, I don't believe .NET is optimal for Internet Start-Ups. Most of the pro-web talent are in Ruby/Python/node.js camps where they enjoy first class support of all the popular web DSL's (e.g. less, sass, jade, handlebars, etc). As well as all the bundling, optimization and minification tools which were available for years in other platforms and have only recently been a supported option in .NET with System.Web.Optimization. The pro-web (Single Page App) community is relatively non-existant in .NET. E.g. none of the showcase apps on http://backbonejs.org (the most popular SPA JS fx) are in .NET.
The ASP.NET website packaging model doesn't scale (productivity-wise), since the larger the website becomes the slower build/iteration times get - which is especially important for start-ups. I do believe typed languages are better suited for typed back-end services - I just no longer believe in them for fuzzy development tasks like UI/HTML generation, automated scripts, etc.
That may be so but when selling software to large enterprises then .NET really helps. I think I would be safe in saying that most enterprises will have Windows OS somewhere in the data center. We've just built a product from the ground-up using MVC 4 (yes, beta) and it is just about to ship -- plenty of pre-orders already and the IT Police just let's us "in".
.NET is the only way I would personally want to go when targeting large enterprises with products.
On Windows many new desktop applications are now being done in C# actually.
In the game industry, the game development tools which used to be developed in C++/MFC are now being coded in C#.
Microsoft is hiring compiler developers to implement native code compilation in their C#, if you search their careers portal.
Before Mac OS X, open source was also unheard of at Apple, if it wasn't for their despair at the time and the NeXTStep team, I am not sure if Apple would have so much open source projects.
It looks like they've started their big Open initiative after they found a business case for it with Windows Azure where almost everything OSS'ed in recent times runs on it.
When you're a cloud provider it makes sense to appear "more open" and support as many technologies as possible == more customers - which is good from the broad developer community as we would have never have seen their node.js on Windows support otherwise.
Is Entity used a lot? We looked at using it but it seemed to be inferior to NHibernate (don't remember details, think there was a problem with type error detection and other stuff).
I don't like it, and we don't use it at Fog Creek, but, yes, it's VERY heavily used on piles of projects I know. It's not as efficient or flexible as NHibernate, but it's far easier and vastly better integrated into Visual Studio, making it a bit of a no-brainer for simple persistence needs.
So, what do you guys use at Fog Creek. I've been discussing with my colleagues some of the micro-ORMs like Dapper, Massive, or PetaPoco as an alternative to EF.
Just to give my 2c, EF is not so much an alternative to Dapper/Massive/PetaPoco as an alternative to NHibernate.
Both are "heavy-duty" orms, while those 3 are more lightweight. My personal view is that for writes and maintaining a domain model, NH (or EF, but I prefer NH) is a good option, and when you need performance or just want a light layer to ease the mappings from sql to objects, micro-orms are the best option.
I don't know what they use at Fog Creek, but I will say that I've been building a lot of things lately in both Massive and PetaPoco, and I've really enjoyed it. I've done several projects in both Linq2SQL and EntityFramework at this point, and they both seem way too 'heavy.' Writing straight sql (or pretty much straight sql) has been a return to simplicity. it's forced me to make sure my queries are efficient, and only return what they need to return.
I do miss using Linq to query the db, but not enough to make me go back. I use EF in my main job, and while it does the job, sometimes I find myself being constrained by the framework. That's not an issue with EF so much as it is an issue with any kind of ORM.
PetaPoco has been excellent so far. I really like being able to easily switch between dynamic and strongly typed results. If you're not doing "Select * on <table>" the dynamic result is pretty necessary.
I do see where there could be some ways to improve querying the database where you're doing a lot of joins or returning data that is not limited to the table design at all.
Kiln uses LINQ to SQL and Dapper, for the same reasons StackOverflow does: the combination combines speed with flexibility. We expect to ditch one or both in the medium future (we want to support more than just SQL Server), but it's a good fit for the moment.
EF is horrible. I've every version since V1. Every system I've worked on that used EF needed major code tuning under production work loads. Before compiled queries (4.1? 5?) supporting more than a handfull of users concurrently was hard. Plus it is just a leaky abstraction over SQL. Many hours spent running stuff through EF, looking at the reams of SQL produced, and trying to tweak the EF query to produce the desired SQL. NHibernate or Dapper or even plain ole' stored procs are preferable to me.
I've used NHibernate, Linq2Sql, and Entity Framework in real projects. I like EF the best, particularly EF Code First. I'm not fond of NHibernate's configuration files and lack of linq support. EF Code First has its quirks too, but seems very lean.
But NH has other methods of querying that are readily available. EF doesn't make those as accessible.
I was able to put in full text function support in NH HQL rather easily in an app and I don't see that ability in EF. I'm working on a desktop application and the ability to precompile the dynamic proxies would help the startup time of the application. I would love if I could do that in EF, I've done it before in NHibernate.
I've used it on a few projects. I have never used NHibernate, so I can't really compare them, but I really like EF. I don't have a great deal of SQL experience, so I'm much better at writing queries with LINQ methods and prefer it over SQL. It's great having strongly typed entities and the intellisense is awesome, but that's probably true with any ORM.
The company I work for uses it, I'm not thrilled - it's still rough around the edges and I'm used to writing my own SQL, but it gets the job done on the few projects I've used it (I only used V1 which was very bad).
V1 was lousy. EF5 Code First is pretty cool (combined with a micro-ORM for specific queries that might need a perf edge) and EF6 will support async and await.
I've noticed you've made great strides with the latest versions, and Microsoft support here in Uruguay has always been great (in particular Pablo Garcia which now moved to Chile).
Keep up the good work :) .
Edit: I'm not on the team, but we're doing one of our main new projects with EF v4.
I don't have any proof to provide (and if I did, it would all be anecdotal) but I've heard rumours that Microsoft are planning on breathing life into codeplex and have an exciting/significant set of changes in the pipeline (which should improve on some of the things that make using DVCS painful).
Considering Team Foundation Service, project Kudu/Git deploy on Azure etc. it makes sense to think that Microsoft are making a play to seriously take on GitHub and Atlassian, so that they're the one provider that owns an entire software ecosystem, end to end.
Either way, I don't think that the EF team would have had a choice on where to host it...
Usability. [Which isn't to say that there aren't great front-ends, but just that DVCS has a reputation for poor usability and a Microsoft solution that's pretty good and easy to use (especially for TFS users) would likely be well-received.]
EF is another overly architected + bloated fx from Microsoft. It's over 12x slower than other Micro ORMs like Dapper + OrmLite - Benchmarks at:
http://www.servicestack.net/benchmarks/#dapper
The benefit of Micro ORMs is that they bind to clean re-usable POCO's (which by nature can be re-used as DTO's, ViewModels, etc).
Most of them also add features as DRY extension methods over the underlying ADO.NET System.Data.* interfaces, so there's no magic behaviour or heavy abstractions happening underneath, letting you add new features orthogonally (by adding your own DRY Extension methods in your own project), and you always have direct access to ADO.NET IDbConnection so you're never restricted when you need it.
Not sure which version of EF those benchmarks are using, or how representative it is. For what it's worth, the EF team has been focusing on performance for EF5 and is making some promising improvements:
The benchmarks are from StackOverflow's Open sourced Dapper ORM project - the source of which is contained in their repo: http://code.google.com/p/dapper-dot-net/
If you guys are so "open" why aren't your performance advances compared in context against other ORMs? Benchmarks means a lot more in context and are more meaningful when they're compared to alt fx's on the same hardware specs / RDBMS / network configuration, etc.
But I guess it doesn't matter when you're still be the most popular .NET package http://nuget.org/packages (580k) whilst remaining more than a factor of times slower than the competition - that's the .NET OSS ecosystem for you.
That's selecting a single db row, feel free to extrapolate that out for multiple rows containing complex queries performed concurrently by multiple users. But I guess performance doesn't matter in places where EF is used.
But that's just it, you don't extrapolate benchmarks outside the context of the benchmark. Without testing it you don't know if selecting 2 rows an extra 1ms, 200ms or 0.001ms. Many ORM have high overhead per query but are optimized to handle large result set's so depending on usage loading 1,000 rows might be faster than it's competitors.
PS: A lot of frameworks are actually setup to handle the least important case first, handling large result sets are generally more important than the overhead for tiny query's. It's nice to be able to for things to work so a query that returns 1/2 million rows still returns in 1/100th a second and you can start paging through that result set even if the behavior adds overhead in the simple case. Chances are there is a shortcut if you only want 1 result just look for .first or a similar shortcut.
You realize the overhead is simply in row mapping right? Naturally this problem only exasperates with more rows.
Like most heavy ORMs it's not obvious what SQL a complex LINQ statement emits where it's common to fall into "pits of failure" where it converts to multiple sub selects or the worst case N+1 queries. I'm personally not a fan of Heavy ORM's their an abstraction over a simple DSL and EF remains unnecessarily bloated and complex.
BTW we do measure + profile, and EF is amongst the worst performing ORMs out there. Please provide benchmarks to the contrary?
As to personal benchmarks. The last set of tests I ran the direct ORM overhead consisted of between 0.2% and 2.3% of our page load times so we promptly focused on things that actually mattered (mostly JS). The ORM advantage is mostly in being able to get a demo to work quickly vs. spending less time optimizing complex queries, which means you only really spend time looking at the slowest stuff which can warp how you look at things.
PS: If you have demo's that EF adds linear overhead feel free to show it but I have pulled 1,000 rows in under 1 second so I suspect your have messed up your setup somewhere.
Yes, I've given it up because of inefficient emitted sql, broken LINQ > SQL magic (leaky abstraction), poor support of alternative RDBMS's and didn't run on Mono.
Partly as a developer who enjoys open source software, but also in part because decisions like this makes life much easier, when you suggest using open source in some a large corporations, where they have a very conservative approach to open source.
I believe if you are building mobile clients and need to target more than one platform you should do your UI with the native APIs on each platform, but should use something like Mono to achieve as much code-reuse as possible for the lower layers of your app.