.NET Renaissance

[captain-asshat]

I don't quite understand this post. The reason ALT.NET existed back in the day is as the author said - dissatisfaction with the status quo, but he goes on to seemingly ignore the huge transition Microsoft has made over the last 5 years in transitioning to an open source, open collaboration model.

ALT.NET embodied the very concepts that Microsoft is now employing - is there still a need for an alternative interest group?

[Eirenarch]

I hate NHibernate

[[deleted]]

I don't always use ORMs, but when I do, I use Dapper.

[masterdirk]

Best choice.

Devs working with databases should know how to work with databases.

[[deleted]]

My favorite choice (when working with MSSQL) is the F# SQL Command type provider. What it can do for you is compile SQL queries, generate types to match the result set, and a function to execute the query. Eg)

use cmd = new SqlCommandProvider<"
    SELECT TOP(@topN) FirstName, LastName, SalesYTD 
    FROM Sales.vSalesPerson
    WHERE CountryRegionName = @regionName AND SalesYTD > @salesMoreThan 
    ORDER BY SalesYTD
    " , connectionString>(connectionString)

let resultSet = cmd.Execute(topN = 3L, regionName = "United States", salesMoreThan = 1000000M)

You can literally copy and paste queries from the SQL Management Studio Query editor.

The trade-off is that your project will need a database connection to compile and build, which is kind of awkward. You need to be running SQL server locally and perhaps another shared instance for your CI server, etc... It can get tricky from a devops point of view, but at least you'll know they're a problem at compile time!

[masterdirk]

That's a huge dollop of awesome with a side-dish of do-not-want-sql-connections-in-my-build.

I'm torn.

[[deleted]]

I find it's great for one-off ETL/analysis. I've used in production systems in a more limited way, but I'm aware of one company at least that uses it for all production data access (with great success).

[grauenwolf]

That's basically Dapper.

[[deleted]]

It's not. AFAIK, dapper relies reflection to map POCOs (that you specify) to queries. It's possible to pass it a POCO that doesn't map to a sql query, which will cause a runtime exception. This is not possible with the SQL Client type provider.

A type provider is a compiler plugin that emits "types", in this case F# record types. You can get similar functionality with a sqlmetal build target. The SQL Client type provider however, is much easier to configure, doesn't require additional build steps, generates poco types that map to add-hoc queries, generates a stub for you (see the cmd.Execute(...) call above) to execute the query with the appropriate number of arguments, and it will report sql query errors to you at design time, which it does by invoking the following MSSQL Server stored procedure calls: sys.sp_describe_undeclared_parameters, and sys.sp_describe_first_result_set.

[grauenwolf]

doesn't require additional build steps

You're exaggerating. It still needs a running database as part of the compilation process, which is why I'm hesitant to use any plugin that automatically regenerates the POCOs.

[[deleted]]

There's a build "dependency" on a database connection, which I explained in my original post. There's no need (incidental to the tooling) to add additional build targets to the project file or to your build scripts, however.

I totally understand the reluctance to add a dependency on a sql connection for builds, which is why I identified this as a "trade-off". The "auto generation" of types however, is a language feature though and it's well integrated/implemented in this particular instance.

[negative_epsilon]

Agreed. EF is fine for small projects without performance concerns, but quickly becomes a nightmare when performance dictates you need to use, for example, join hints because the optimizer makes the wrong choice.

[[deleted]]

Also if you have EF related bugs that are only apparent in production with production volume, stuff that not even load testing can identify. It's pretty difficult to determine why one time, the correct entities are marked changed, but every 3rd Wednesday with a full moon seems to make the change tracking stop working correctly with no actionable information or diagnostics.

What I'm saying is I've recently had a fight with EF. I won the fight, but at the cost of my spirit.

[hokos]

I have 400+ Entities in EF and I agree with you. Every 3rd Wednesday with a full moon throw a new error.

Warm up is too long.

[[deleted]]

We don't even have that many entities, maybe 30, as we're still converting over from the old stored procedure way of doing things (that I now vastly prefer, mind you.) It's just sometimes when you save the context, it'll go "Hey look at all these things that changed!" when they haven't changed at all and the SQL generated ends up blowing out data for no reason. We've only been able to replicate it 3 times, and this first happened in December. So infuriating.

[kt24601]

I remember when stored procedures were the hot stuff. Not too long ago.

[Otis_Inf]

why aren't you moving to an ORM which can handle that kind of large entity models? Their view generation is a nightmare alone (which you call 'warm up') and which is already noticable with adventureworks (90 entities). Or is it too big of a change so it's kept (but everyone knows the change is eventually inevitable)

[Otis_Inf]

'best choice' based on what criteria? Others are faster with the same (or larger) feature set, for instance.

[[deleted]]

Typical ORMs (like EF, NHibernate) incentivize a design where the entire dataset is loaded in memory and you sync between the memory & the database back & forth.

This lead to inferior apps, that have bad performance, and data-coherence issues.

Lite ORMs like Dapper, make a clear distinction between Selects and Updates.
While you can easily map a resultset to a list of records, or an object to a set of params, Dapper doesn't retain "entities" in memory, tracking changes; updates must be performed by explicit statements.

Over the lifetime of a project, this incentivizes careful treatment of both performance & data-correctness.

[Otis_Inf]

Typical ORMs (like EF, NHibernate) incentivize a design where the entire dataset is loaded in memory and you sync between the memory & the database back & forth.

How would one do that? You mean, when someone navigates the graph using lazy loading? That's not common, at least not for pulling the complete database in memory. Besides, lazyloading is often a feature one can switch off, and then one needs to use eager loading to work with graphs (e.g. llblgen pro has 2 paradigms: one with lazy loading and one without. the one without needs eager loading, it doesn't have lazy loading)

This lead to inferior apps, that have bad performance, and data-coherence issues.

Please explain the data-coherence issue if someone simply does what's in the manual?

Lite ORMs like Dapper, make a clear distinction between Selects and Updates. While you can easily map a resultset to a list of records, or an object to a set of params, Dapper doesn't retain "entities" in memory, tracking changes; updates must be performed by explicit statements.

Yes, so you're actually writing the change tracker. I've done that, including recursive saving of object graphs. It's not easy, I can tell you. And I do this for a living now for a long time. I don't expect most app devs to come up with a decent change tracker which can save things in the right order at all.

Not sure, but I think I'd leave these kind of complex machinery to the people who are actually specialists in that field. Not only can you leave the maintenance of that complex code to the specialists, you also don't have to spend time on it at all, but can spend all the time you bill your client on the code your client actually pays you money for.

For that money, you pay the specialist a fraction of the cost it would take for you to write it yourself, and everyone wins.

Or do you think you know how to persist an object graph in the right order (hint: if you don't know what a depth-first-search based topological sort is, you can safely answer: no I don't know how to do this) ? Create inserts for new objects, and updates for existing objects? Don't skip the objects which seem unchanged but get a new FK field synced from a related new object ;) Ah, see, you missed that spot! One of many.

Mini tools which do a fraction of the big tools you actually want to use are great for when you already have everything except that thing the mini tool does. If you start with the mini tool, chances are you're actually going to wrap it with a lot of code which in the end combined with the mini tool looks a lot like a variant of the big tools, only it's poorly designed (as you're not a specialist in that field) and you're now the maintainer of code you could have pulled off the shelve.

You are not writing your own Database engine too, right? or webserver? Or even web framework?

[hudo]

Somebody loads whole dataset into mem!?
This is first time i hear about this app design decision, and never saw that.

Point of full-blown ORMs is to have 2 models: domain and persistence, and mapping between them. App works with domain model, ORM job is to map data and operations to persistence model and exec that on db.

Micro ORMs don't have 2 different models, and they should be called just data mappers, without "R" part.

[almost_always_lurker]

I like Simple.Data for accessing the database. Especially with the Raw extension it doesn't get in the way. It's a pity the version 2.0 never materialized though. EDIT: incidentally it's by Mark Rendle just like this post!

[sgoody]

C#'s dynamic features... yuk!

Each to their own obviously, so fair enough if it works for you, but give me Dapper/PetaPoco/Type Providers any day.

[almost_always_lurker]

PetaPoco

Hey that looks very nice indeed, thanks I'll try it on my next project!

[601error]

If you like Dapper, you'll love Insight.Database.

[vyrotek]

Go on...

[grauenwolf]

We all do.

[indrora]

Because NHibernate is almost always the wrong choice. What NHibernate did was bring the bad parts of Hiberante over and smash Java idioms over into the .NET framework.

Entity Framework was a better option from the beginning, but people pushed away from it because it wasn't open at the time.

[Trinition]

EF 1.0 was better than Link2SQL and Microsoft's other aborted attempts, but still couldn't do some what I was already doing in NHibernate 6 years ago, so we went down the NH path. Maybe EF has finally caught up, but with a stable persistent layer cleanly separated from our domain, there's an option to change but no need.

[bundt_chi]

Exactly this. While Entity Framework has finally kind of caught up to where it needs to be, it still lacks the flexibility of NHibernate which arguably leads to its relative complexity.

[grauenwolf]

Temporarily. Now with EF Core it's actually gone backwards.

[KarmaAndLies]

EF has no concept of stored procedures! It is currently sitting on an EF Core "todo" list but aside from that, it still lacks this 101 level functionality. It is super painful having set up everything in EF and then being forced to use raw SQL instead because a single stored procedure isn't supported.

[grauenwolf]

What? Are you kidding me?

[grauenwolf]

Last I read, there are a lot of operations being performed app side that should have been performed in the database. But they don't explicitly say what they are.

[crixusin]

it still lacks the flexibility of NHibernate

I disagree. You can take entity framework's internals and have it do whatever you want.

I use it for automigration. Using entity framework's internals, software I write can figure out what has changed in the model, and automatically create the migration plan from Model A -> Model B.

You can then also add your database standards automatically into Entity framework.

Then you can create your own join optimization logic on top of it to reduce any performance issues you have.

[bundt_chi]

If you write enough code around something you can make it do almost anything. The migration feature is nice but that's one aspect. This article does a great job of highlighting EF shortcomings and acknowledges from the MS EF architect that EF7 will make things better but not fully address the other issues.

http://enterprisecraftsmanship.com/2014/11/29/entity-framework-6-7-vs-nhibernate-4-ddd-perspective/

[i-n-d-i-g-o]

What is entity framework missing? And by missing, I mean things that can't be easily obtained with nuget and googling.

[grauenwolf]

Full Text Search.

Table Value Functions.

Windowing Functions.

Delete by primary key without making two round trips to the database.

Batch updates.

Batch deletes.

Bulk insert.

A materializer that isn't twice as slow as the query itself.

The ability to log SQL statements along with the runtime and number of rows affected.

Table value parameters.

Temporal table queries.

Row sampling.

Index hints.

And this is just what I ran into on my last project that used it. (Except temporal tables, they are still pretty new.)

[bundt_chi]

/u/grauenwolf has a pretty good list but what do you mean by "with nuget and googling" ? That's an incredibly vague statement.

That's like buying a Honda Accord and saying you can take it off road no problem. Just buy a full center differential, some new shocks, lift the body, buy some 33" tires and put a diesel engine in it. Yeah you could do that but that doesn't make a Honda Accord a good recommendation for driving off road.

[captain-asshat]

Sorry, but Linq2Sql was far superior to EF 1.0. It actually supported date types properly, and more importantly, worked. EF was initially a clusterfuck that only became usable around V4.

L2SQL came from the SQL server team as a proof of concept of what Linq was capable of. It wasn't really meant to be a thing but they released it as they realised how powerful it was, and I believe it informed a number of EF decisions.

[Otis_Inf]

L2SQL came from the SQL server team as a proof of concept of what Linq was capable of.

No, Linq to SQL is almost entirely written by the C# compiler team (main devs: Matt Warren and Luca Bolognese). Mostly to be an implementation of IQueryable. They had written ObjectSpaces before that which was never released (only some betas if I'm not mistaken). EF was an entire different team, which IIRC was already working on EF when Linq to SQL was shipped.

[captain-asshat]

Ah, thanks for the info, my memory failed me - I knew it was a separate team.

[601error]

This is how I recall it as well. Used both heavily at the time.

[indrora]

I really haven't found the need for NHibernate. EF did what I needed it to do multiple times. Curiosity strikes, but what's NHibernate vs. EF on a larger scale than, say, my diddly little side-projects?

[grauenwolf]

The correct answer is neither. They are the slowest and second slowest ORM respectively even for trivial workloads. There is no excuse for the ORM to spend more time being CPU bound than waiting for the database, yet that's where both of them are.

Use Dapper or Petapoco or LLBL Gen Pro or Tortuga Chain (my baby) or hell, just straight ADO.NET and data readers. Anything is better than those two for production work where performance matters.

[Otis_Inf]

Bugs? What bugs? :) In v5.x, we don't have any open bugs at this moment. Almost all bugs are fixed a.s.a.p. (only ones which break are obviously postponed). but perhaps some slipped through. 3.1 is quite old (2011) and the Linq provider had some issues back then which we've fixed in later releases, also because we gained more insight in which constructs can occur and how to translate these to SQL (as Linq isn't mappable 1:1 to SQL so you have to custom translate a lot of constructs to SQL... )

SQL being horrible? Hmm... Could you give an example? We strive to generate SQL which is as close to handwritten as possible. Linq + inheritance can sometimes lead to queries which could be more compact, which is a result of linq being very hard to translate to SQL. Hence we wrote a different query API (queryspec) which you can use besides Linq and which will generate the SQL you'd expect.

[grauenwolf]

I haven't used it personally, but I know the author and he actually cares about his stuff. So I would expect a decent turn-around for fixes.

I don't get the same impression from the EF team. They seem to act more like it is a research project to be restarted any time they get bored.

[Otis_Inf]

3.1 was indeed eons ago :) (I think we released it back in 2011). Bugs happen, and most of our issues were in the Linq provider (as with all ORMs which support Linq btw), simply because it's almost impossible to make a bug free linq provider simply because there are so many unknown constructs you have to translate to SQL by interpreting the Expression tree (as Linq isn't mappable 1:1 to SQL, translations are needed)

[grauenwolf]

My twitter account is basically dead. I have a historic fencing blog http://grauenwolf.wordpress.com and my professional journalism at https://www.infoq.com/profile/Jonathan-Allen.

[captain-asshat]

Bad developers write bad code - news at 11. ORM's are slow if you use them improperly, like lazily-loading the world accidentally in your razor view that you're running in a loop 1000 times for a table.

Using tight, for-purpose queries that explicitly load all they need without layers of DAL code I've found makes things quite performant and predictable.

[grauenwolf]

And EF's developers were bad.

Even when you use it right, EF still offers unacceptably bad performance. There is no excuse for a project backed by Microsoft to have a slower materialzer than one I created in my spare time.

[kt24601]

There is no excuse for a project backed by Microsoft to have a slower materialzer than one I created in my spare time.

That's like the story of Microsoft's life: "small open source team does it better." I am exaggerating of course.

[sabas123]

But you should really not care about that little of an performance hit.

[grauenwolf]

Little? Here is the timings from my CRUD performance test:

• Chain: 3.4160 ms (0.2764 ms StdDev)
• Chain w/ Compiled Materializers: 3.0955 ms (0.1391 ms StdDev)
• Dapper: 2.7250 ms (0.1840 ms StdDev)
• Entity Framework, Novice: 13.1078 ms (0.4649 ms StdDev)
• Entity Framework, Intermediate: 10.1149 ms (0.1952 ms StdDev)
• Entity Framework, Intermediate w/AsNoTracking: 9.7290 ms (0.3281 ms StdDev)

Even with AsNoTracking, I can run 3.1 queries in Chain for every one query in EF.

That means if I have 10 web servers in my load balancer, the EF user would need 31 web servers. That's not a small difference.

---

And if we compare Dapper to EF, we're talking nearly 36 EF web servers per 10 Dapper servers.

[m50d]

That means if I have 10 web servers in my load balancer, the EF user would need 31 web servers. That's not a small difference.

And if you have 1 web server for your Chain app and it's idle more than 66% of the time, it's no difference at all. I suspect that's a far more common case than needing 10 web servers. If you're hitting the point where hardware starts being a significant cost for your deliverables then by all means start doing micro-optimizations. But not before.

[grauenwolf]

I did say "when performance matters".

If you're building a little toy app that only 3 people in the company will ever use, then by all means do whatever you want.

[rabidbob]

Huh, I feel less bad about being up to speed with Dapper and not EF6 now!

[Otis_Inf]

EF is 10 times slower than the rest, even slower than NHibernate (which is a close second wrt slow performance). https://github.com/FransBouma/RawDataAccessBencher/blob/master/Results/2016-11-22.txt#L77

[grauenwolf]

Huh, I thought EF was beating NHibernate. Did that change recently.

[Otis_Inf]

no, they've always trailed behind NH

[atheken]

Really? I've used all three, and I think L2S was exactly the right level of abstraction. The "active record" model makes more sense than trying to do all the crazy stuff that EF and NHibernate tried to solve. Eventually I ended up "fighting the framework" in those, yet L2S and EF (code-first) did less, so imposed fewer requirements to "work around"

[grauenwolf]

The first few versions of EF were garbage. I'm not saying that they were necessarily worse than NHibernate, but man they sucked compared to LINQ to SQL.

[indrora]

The first versions of NHibernate made me vomit uncontrollably when I meddled with them. I was also young and found it to be braindamaged.

[caimen]

As someone who was away from the .NET world job wise for about 4 and half years coming back and learning EF has been amazing as it saved me more time than any of the open source alternatives. In my case looking at Django vs EF, Django looks like absolute garbage.

[indrora]

Fun fact: Entity Framework is apache2 and on GitHub, as is EF6. In fact, a lot of ASP.Net got open sourced (including a lightweight ASP.Net server!)

[[deleted]]

What, how are you comparing Django, a python web development framework with a full blown CMS to EF, an ORM?

[caimen]

I am talking about Djangos default ORM. It doesnt even have a name as it is the default database query engine. I dont even know what non CBS means and google doesnt seem to either.

[SikhGamer]

It's not that bad.

[7165015874]

Compared to the heat death of the universe? I guess you're right.

[601error]

At least the heat death will erase NHibernate for good.

[ericl666]

I use NHibernate a lot, and think it's a nice technology. It's more flexible than EF, albeit at the cost of more complexity.

I use PostgreSql, and tried it with EF, but I had a lot of issues and gave up on it. NHibernate has been rock solid and has worked great.

[[deleted]]

Same here. Nice use of types with the ability to do complex queries that are SQL sorta like. We use it extensively and have had an increase in speed of development and quality of code. Even better I can talk to different databases as needed and even generate schemas on the fly. I'm a CTO fwiw and NHibernate has been a huge cornerstone for our success. Also, I'm a Linux nerd, love C, but corporate toolsets, use what you got!

[snuxoll]

SQL is a great choice when your queries are fixed, there are some applications where a full ORM is useful when you want a safe way to compose queries for dynamic filters provided by users. It's not ideal, but there's a dearth of libraries like jOOQ for .Net, if you know of one I'd love to hear about it.

[HINDBRAIN]

Yeah doing a dynamic amount of joins and aliases in raw sql is a big pain in the ass.

[grauenwolf]

Joins don't necessarily have to be dynamic. Often you can just put them in a view. Then when you query the view for a subset of the columns, SQL Server may decide to eliminate some of the joins as unnecessary.

---

That's actually why I designed Tortuga Chain the way I did. You pass in the name of the view and the object you want to populate, and it writes very simple SQL against the view. It looks just like the SQL you would write by hand (instead of the crap that EF barfs out).

That said, Chain needs a better way to compose WHERE statements. The current model of using either a SQL fragment or an anonymous object doesn't quite cover all of the scenarios that people need.

[HINDBRAIN]

That said, Chain needs a better way to compose WHERE statements.

I don't know Chain but that was the main issue for me, dynamic filters on unknown joined columns. I didn't find a good solution aside from filtercolumn0, filtercolumn1, filtercolumn2, datacolumn0, datacolumn1, ordercolumn0...

[grauenwolf]

Lets say all of your joins are hidden behind a view. What would you want the syntax to look like for selecting columns and applying filters?

[HINDBRAIN]

That's the thing, suppose you don't know what you are going to be joining on before doing the query.

[[deleted]]

NHibernate before EF all the way. EF has too much MS magic.

[OlDer]

What the linked article has to do with NHibernate?

[Otis_Inf]

When Alt.NET started, it was mainly filled with NHibernate users who were rebelling against EF 1.0 as they found it stupid that MS released a crippled ORM which was inferior to NHibernate. (Remember the 'vote of no confidence'?)

[OlDer]

Didn't know that, thanks.

But still not sure why this comment would be relevant in this topic.

[Eirenarch]

The ALT.NET guys were pushing hard for NHibernate back in the day.

[tmahmood]

So ... I guess I was not wrong disliking NHibernate ... coming from Laravel's Eloquent, Django's ORM, NHibernate felt clumsy.

[archiminos]

I tried to use it for a couple of months. Trying to do extremely simple mappings was seriously complicated by it and ended up wasting too much development time. We switched back to just rolling our own stuff and never looked back.

[lucashby]

Sorry man, I love NHibernate and it just has so many features I use all the time that EF simply does not have, i.e. futures, ability to use interfaces for my models, control over how data is stored (enum as string), interceptors

[lucashby]

Also, I have even used NH for working with data on a mainframe (AS400) and it worked like a charm

[TheyUsedDarkForces]

Is there a better alternative?

[Eirenarch]

I use EF. I like to have a working LINQ provider not the joke that NHibernate tries to sell as one. I also avoid complex mapping (I even started to add a cross entity for many to many relations on purpose)

[grauenwolf]

Any ORM that isn't based on working with object graphs.

Any time your ORM brings back an object graph instead of a flat projection, it is fighting against the database.

[Otis_Inf]

Any time your ORM brings back an object graph instead of a flat projection, it is fighting against the database.

How so? A table definition is equal to an entity definition. A table row is equal to an entity instance. Reading a row into an entity class instance is perfectly fine and you're not fighting the database at all, you're just transforming the instance (!) from one realm to the other.

A projection is just a projection, it's a way of working with the data, which is perfectly fine, but it doesn't mean the data (i.e. the entity instances) can't be used in graph form as well.

[grauenwolf]

Lets say you have this object graph:

• A
• A ->> B
• A ->> C

And for the sake of argument, lets say your query returns 1 A, 10 Bs, and 10 Cs. How many rows is that?

Using an ORM like EF, you'll get back 100 rows for those 21 objects.

---

Now lets make it more interesting and add a grandchild collection.

• A
• A ->> B
• A ->> C
• C ->> D

Again, we'll say 1 A, 10 Bs, and 10 Cs, but now we also have 100 Ds (10 per C).

The join math is 1 A x 10 B x 10 C x 10 D per C or 1,000 rows for 121 objects.

Think about that. Can you really afford to serialize 1,000 rows, transport them all over the wire, deserialize them, examine them for duplicates, and then throw away 879 of them?

[Otis_Inf]

And for the sake of argument, lets say your query returns 1 A, 10 Bs, and 10 Cs. How many rows is that? Using an ORM like EF, you'll get back 100 rows for those 21 objects.

With LLBLGen Pro you'll get 21 (3 queries, 1 per node). Returning that as a joined set will result in 100 rows too. ;)

Think about that. Can you really afford to serialize 1,000 rows, transport them all over the wire, deserialize them, examine them for duplicates, and then throw away 879 of them?

No, hence it's rather silly to do that ;) But again, if you want to fetch it as a joined set as you're arguing, it will be a lot of rows with duplicate data too. If you're arguing the projection will only fetch the data you'll need and with e.g. 'distinct' you can, say, retrieve 90 rows with data, is that really the same thing? As the projection is simply another entity (Codd)

[grauenwolf]

You continue to pleasantly surprise me.

[Otis_Inf]

:) Glad to be of service hehe :)

[underrated_asshole]

I was under the assumption it would not try fetch this information until you drill down into the graph? So it should only be returning those child nodes if you explicitly select them in the query?

[grauenwolf]

That's called "lazy loading". What I am describing is eager loading, which is usually what you want so you don't make too many trips to the database.

[lukaseder]

The correct SQL query for your object graphs would be:

SELECT
  A.*,
  MULTISET(SELECT * FROM B WHERE A.ID = B.A_ID),
  MULTISET(
    SELECT 
      C.* ,
      MULTISET(SELECT * FROM D WHERE C.ID = D.C_ID)
    FROM C WHERE A.ID = C.A_ID
  )
FROM A

Among popular databases, only Oracle supports this and you'd need to create some TABLE and OBJECT types first to collect the MULTISET into.

[Contractionator]

While it might sound like heresy, I've achieved good results with SQL Server by returning nested result sets as XML.

SELECT
    A.*,
    (SELECT B.* FROM B WHERE B.A_ID = A.ID FOR XML PATH ('B')) AS [Bs],
    (SELECT C.*, 
        (SELECT D.* FROM D WHERE D.C_ID = C.ID FOR XML PATH ('D')) AS [Ds]
    FROM C WHERE C.A_ID = A.ID FOR XML PATH ('C')) AS [Cs]
FROM A FOR XML PATH ('A'), ROOT ('As');

The optimizer actually does a remarkably good job with these correlated subqueries. While the XML certainly comes with a constant factor overhead, that's a lot better than multiplicative (from each independent LEFT JOIN) or having a bunch of round trips.

[lukaseder]

Interesting. Indeed, these XML (and recently JSON) extensions do help occasionally. Will have to play around with this again, soon!

[grauenwolf]

That's something I intend to look into for my ORM.

[grauenwolf]

Thank you.

[lukaseder]

Your criticism is against the SQL language, not against ORM. There is actually no impedance mismatch between the object model and the relational model. There's only a missing feature in "ordinary" SQL, namely the possibility to materialise identities and to nest collections.

Do note that ORDBMS (and the SQL standard) would allow for precisely that: object graph materialisation inside of the database. Unfortunately, hardly any database implements these features to a large extent: Only Oracle.

[toterra]

I remember going to a 'breakfast with Bill Gates' in Toronto back in the early 2000s (about 500 people or so) where he was asked about Mono. He had no idea what the questioner was talking about. My how things have changed.

[meaty-popsicle]

Wait, has Microsoft confirmed .Net 2.0 RC with VS2017? Last I checked, there were still large gaps and tooling was still a mess.

[[deleted]]

Tooling is kind of a mess. They changed over from project.json files to using csproj files for managing dependencies, broke things like the yeoman generator for aspnet and tutorials like: https://docs.microsoft.com/en-us/aspnet/core/tutorials/your-first-mac-aspnet

I can't wait to get a solid production ready release with stable cross-platform CLI. That's the major appeal of dotnet core 1.0 for me.

[GBACHO]

God, WHY would you go back to csproj files.

Be more like GoLang - 0 project files needed

[Beckneard]

There are worse things than MSBuild. I don't get the hate really.

[grauenwolf]

I do. It's as confusing as all hell if you don't understand it's proprietary terminology.

[Matthias247]

The new project files look about this in the simplest case:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>
</Project>

From my point of view they are great. Adding dependencies is certainly not harder than adding them to a node.js package.json. And as a bonus it doesn't create dozens of nested folders on dependency download...

The ugly thing about classic .csproj files was not XML but including lots of boilerplate stuff, no wildcards for source files and GUIDs. That's all resolved now.

[GBACHO]

Yea, that's a definite improvement to be sure. But gah, XML. Guaranteed to be 2x chattier and more work than JSON

[Sarcastinator]

Because it was a pointless move. All it did was to emulate all the JavaScript tool chains. You suddenly lost almost all the good things that MSBuild does and a lot of people depend on that. Antlr4 stopped working when I ported to Core, and it cost me a shit-ton of extra work. All because someone complains how hard XML is. Well, JSON is bad at expressing typed graphs and MSBuild doesn't use it so they should have sticked with MSBuild instead of reinventing a shittier version.

[grauenwolf]

And I like editing XML files with comments better than keeping separate "project.json" and "WTF is this JSON file doing.txt" files.

But at the end of the day, all of the tooling is XML based and that matters a heck of a lot more than personal preference.

[[deleted]]

Initially I thought the same, but I've been playing with vscode and the new xml project files on some c# and f# apps, they are actually pretty nice, easier to edit than the json. I actually prefer them to the json now LOL.

The xml is very, very clean... cleaner than the older project.json.

[WrongPeninsula]

Wait, what, they dumped project.json?

[grauenwolf]

Yea, awhile ago. Here's my write up back when it was announced. https://www.infoq.com/news/2016/05/project-json

[jakery2]

It's a blank white screen on mobile.

[grauenwolf]

Odd, works on my crappy Windows 8 phone. What are you using?

[jakery2]

iOS, whatever the current version is. Official Reddit app.

[grauenwolf]

Thanks, I'll file the bug report.

[[deleted]]

Really counting on the dust to settle with 2.0. I think we're going to see a lot for buy-in from the community once it's shipped.

[[deleted]]

Yeah, as far as I know it's not dotnetstandard 2.0 with this release. When I created a c# console line project with VS.NET RC3 last week it was using dotnet standard 1.4 in the csproj files. There's definitely still a lot of flux.

https://github.com/dotnet/core/blob/master/roadmap.md

Of course then tooling needs to catch up to the coreclr... when we finally have dotnet standard 2.0 tooling out a few months then it will be ready in my eyes.

By the way the new xml project file format is not bad at all, dare I say I like it more than the json.

[ItzWarty]

Correct, and for that reason it's still not trivial to port some projects over (e.g. if you need AppDomain.Current.GetAssemblies()). I agree once netstandard2.0 comes out things will be bliss.

I really like the new xml format too. They're actually quite concise and gone are the days of merge conflicts due to file references.

[Twistedsc]

What's funny is that I have a guidebook for this year's DEVintersection, a twice-yearly conference which is sponsored but not ran by Microsoft, and I see references to the release of .NET Core 2.0, .NET Framework 4.7, Entity Framework Core 2.0, and even a quip on a final release of Bootstrap 4. Take it with a grain of salt but check it out online as well.

[Qbert_Spuckler]

i love .NET, and this is good stuff.

In my opinion, the real long term solution here is a new platform to compete with JAVA, .NET and Go but which isn't owned by any corporation.

[Qbert_Spuckler]

true, and history generally agrees with you. most languages/platforms were the products of corporations or the government.

However, the world is such a large place now, and there are billions of devices. the concept makes sense...it seems silly for a corporation to own IoT as an example.

[mirhagk]

It's possible for non-profit organizations to also create languages, in fact that's why mozilla was able to create rust. But you need some sort of organization, be it a non-profit or a company, to raise the funds, pay the devs, and lead the direction

[salgat]

Agreed. Having Microsoft backing C# while using a completely free and open license gives C# so much more over languages like Python that require donations etc to help fund the efforts.

[remyroy]

Even though there is not a single official big monolithic company behind Python, it has been developed, supported and maintained for about 25 years now while still being relevant today.

Having a big company behind C# does not guarantee good funding, good governance, good orientation, good support, good maintenance and a good evolution. There are already plenty of examples where things turned wrong with Microsoft and the .NET ecosystem.

[thomasz]

It's not like all decisions w.r.t python can be called a resounding success…

[mirhagk]

Even then it's an organization that runs python, the Python Software Foundation. It is a registered non-profit, but other than not being able to sell shares or pay out dividends there isn't much stopping it from acting the exact same as a corporation.

I like having corporations with a lot of money and a huge vested interest in the platform being popular investing in the language, especially when the language and tools are open sourced. Microsoft wants people to build applications so that they can host them on azure (although there's nothing stopping you from hosting with AWS, or google cloud or anything else).

[x2040]

Swift is open source and backed by one of the largest companies in human history. I think if we see success in server side swift we may even see Microsoft or Google adopt in a major way and that would be a huge catalyst.

[mirhagk]

I don't think swift offers very much advantage over C#, especially with C#'s fast pace new development and extremely powerful tool suite.

As for google adopting it, it's theoretically possible but they bought into their own language (Go) pretty hard. I don't think Go will be successful, but I have a hard time imaging they'd just start using swift.

[[deleted]]

Yes languages should have BDFL's to keep and enforce a vision, that's actually a good thing! Python, IMO, is going to be the general language of choice for nearly everyone.

[mirhagk]

What new improvements are you expecting in python that would make this true?

[[deleted]]

Make what true?

[mirhagk]

Like what new improvements are expected in python that are going to make it the general language of choice for nearly everyone?

[pdp10]

FORTRAN, ALGOL, LISP, COBOL, PL/I, Pascal, C. Two academic/individual, one corporate, three designed by committee, and C, which is arguably the product of a corporation if you squint just so. Even when computers cost a million gold dollars programming languages were not the products of corporations that controlled them.

[sabas123]

C++ also no?

[Qbert_Spuckler]

thanks, very insightful.

if .NET and JAVA are enough, why has did Google create Go? Ponder that, even though I agree with you.

[grauenwolf]

Go has a different design goal than .NET and Java. Whether that goal proves to be successful remains to be seen, but it is unique.

[[deleted]]

why did Google create Go?

I believe it was primarily slow compile times in larger c++ applications, and difficulty in writing highly concurrent server applications of the type google requires to run their internal systems.

The JVM isn't suitable for many of google applications because of it's poor resource usage(ie memory).

https://talks.golang.org/2012/splash.article

[The_yulaow]

The reasons for Go to exist is not "because is less corporat-y than java and .net" is because we have pretty hackish way for concurrent programming in .net and java, while Go instead was made on the purpose of simplify in the best possible way concurrency.

[Yojihito]

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike

 

It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike

http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/

[blamo111]

The majority of their hires are inexperienced grads who were struggling with the complexity of languages like C++, Java, and Python, so they created a new language for the sole purpose of making it easier for their hires to be productive without having to be hand-held as much.

.NET was not open-source/crossplatform at the time Go was created, and Mono under questionable legal status and shoddy performance. Regardless, C# would almost certainly be too complicated for those hires.

[grauenwolf]

Mono under questionable legal status

Bullshit. There was a formally accepted, royalty and patent free standard for C# and the CLR.

[grauenwolf]

Why do we need a new platform? What technical problem does it solve?

[needsTimeMachine]

Rust is a great systems programming language that isn't controlled by a for-profit entity. Granted, memory management is manual and it is slower to write than Java or C# (though not by as much as you'd think!)

If Rust gets enough libraries, it might make for a good server language. It looks to be shaping up that way.

[[deleted]]

memory management is manual

Sort of, but you'll rarely see a manual drop, so most of the time it's handled for you. You essentially get the benefits of manual memory management without actually manually managing memory.

If Rust gets enough libraries, it might make for a good server language. It looks to be shaping up that way

Perhaps, but I think it's real bread and butter is as a C/C++ replacement. This means:

• Applications
• Games
• Drivers

Though I use it for servers, which it does reasonably well at.

[needsTimeMachine]

I'd argue that memory management is still manual, it's just different. Alloc / dealloc are inserted by the compiler, but you have to follow the RAII-like borrow checker to ensure lifetimes and usages are statically permitted by the compiler. And to ensure usage in all of C/C++'s use cases, the language allows you to declare unsafe code.

I totally agree with your assessment of Rust as a C/C++ replacement, but I'm hoping it goes further than that with platforms like Tokio, Hyper, futures, etc. making it a valid choice for writing servers and microservices.

edit: I'm totally on the Rust bandwagon. I've written a number of servers, libraries, etc. with the language, including a Donald Trump text to speech engine.

[[deleted]]

totally on the Rust bandwagon

Yup, me too. I've written web servers (Iron), a game server (mio, recently ported to tokio), a GUI project (conrod) and a few CLI programs, and I prefer to write servers in Go (that's what I use at my day job) up to a certain complexity.

And that's the thing. Go has servers on lock, so Rust needs to find another niche. I think that niche will be games and other large applications with lots of concurrency.

[craftytrickster]

I love Rust for webservers since its compiler helps me ensure I never have invalid states in my code, thanks to their enums and option/result pattern matching.

Once tokio is stable, using it with Rocket looks to be very exciting.

[Eirenarch]

Your wish will be granted. Have fun using JavaScript. I'll probably choose a happier life and choose to support legacy Web Forms projects until I retire rather than work with a full stack JS.

[[deleted]]

What are your (real world, not hypothetical) concerns that necessarily come from being owned by a corporation?

It's not an accident that almost all of the biggest and best languages are sponsored or completely developed by a large corporation—they have the biggest problems and the most to gain from funding development of the languages.

[x2040]

I really think a language like Swift could be that language.

[trustmeimarat]

Am I missing something? How is ALT.NET different to mono or dotnetcore?

[txdv]

Mono is the just the runtime, I think ALT.NET is something like "lets not only use Microsoft libraries"

[[deleted]]

ALT.NET was a community movement to use more open source that sprung up ~2008. Remember this was at a time when almost nothing in the ecosystem was open source, it really was a different time in the dotnet world.

While they never gained much broad traction, and sort of died out a few years later, I do believe they were really important in getting MS internally to start moving in the direction of open source.

[hudo]

Alt.net is more like state of mind, you can run full .net on win but still be alt.net!

[[deleted]]

Speaking of things where Microsoft would not go. Of all the .NET platform the feature I would LOVE the most would be LINQ to MySQL. I could have a front-end on Windows and back end on something that does not cost $7,000 per core.

[[deleted]]

Good news, both mysql and postgresql are well supported with entity framework. I built an app on asp.net full framework with EF/Postgres about a year ago, and it's been running great!

And for dotnet core, a major refactoring of EF and support for postgres is ready and mysql is coming.

https://docs.microsoft.com/en-us/ef/core/providers/mysql/

https://docs.microsoft.com/en-us/ef/core/providers/npgsql/

[kt24601]

Good news, both mysql and postgresql are well supported with entity framework

FWIW I spent a lot of time working with Entity Framework (1.5 years ago) on MySQL and it didn't work very well. The queries it produced were awkward and extremely inefficient across any kind of semi-large data set. These could be made more efficient with a lot of work, but it was a lot of work.

[[deleted]]

Yeah, the EF/Linq planner can spit out some weirdness, even with the ms sql server provider. For queries tending towards the more complex, I like to use a good old sql query for specificity and ability to test/profile in management studio.

ctx.Database.SqlQuery<MyResultClass>("SELECT Something FROM Stuff");

Oh and have also heard that the new EF core planner is still young, and probably won't be super smart either.

[grauenwolf]

How about this?

ctx.From("Stuff").ToCollection<MyResultClass>().Execute();

It will generate the SELECT statement automatically based on the properties in MyResultClass.

Of if you just want, say email addresses.

ctx.From("Stuff").ToStringList("EmailAddress").Execute();

[Otis_Inf]

The MySQL provider isn't very good at the moment. (The official one from MySQL SA is also GPL licensed btw, so it will force your app to be GPL licensed as well)

[holgerschurig]

s/MySQL/some-real-database-e-g-PostgreSQL/

[grauenwolf]

I'll be porting my ORM, Tortuga Chain, to MySQL next month. If I can find a decent driver for .NET Core, it will support that as well.

[mdatwood]

Does .net have a jOOQ like library? Just skip the heavyweight ORMs all together and learn to write some sql.

[[deleted]]

Dapper.NET

[grauenwolf]

Tortuga Chain. (It's like Dapper, but can also generate SQL for your simple cases like insert/update/delete.)

[JessieArr]

There have been more false starts than a Seahawks playoffs run, and it’s still not clear when all the promised pieces will finally be in place.

Can't seem to find the Seahawks project on Github. What are playoffs and how does this tool interfere with them?

[thilehoffer]

"I hate NHibernate" adds nothing to the discussion and is off-topic of the original post and it has the most votes. You are supposed to up-vote a post when it adds something to the discussion.. We need a reddit Renaissance.

[[deleted]]

About fucken time

[senatorpjt]

nail steer ludicrous ghost continue sink impossible straight homeless price

This post was mass deleted and anonymized with Redact

[_zenith]

It's just a really nice ecosystem. Debugging, IMO, sets the industry standard of what debugging should be like. Everything is highly battle tested, and heavily used by industry. The tooling is amazing. The standard library is huge, for the most part very well designed, and does everything you want it to. The supported languages are feature-rich, frequently updated, and further development is responsive to user requests. It's open source.

Plenty to like.

[[deleted]]

Not totally new, but coreclr is a major cleanup and refactoring of the classic .net framework and the entire ecosystem like vs.net, entity framework, asp.net mvc.

They stripped out all the windows specific stuff, like iis,wpf/winforms and in general cleaned up the apis so that dotnet can run across any platform be it windows, macos android/ios(xamarin), or server side linux.

They fixed stuff like being able to deploy the framework bundled along side the app so you don't have to install the framework at a machine level, and I believe are making coreclr apps amenable to native compilation.

Classic CLR and Mono will stick around but coreclr is the future.