[TheRealDunkirk]

Yet another piece of mature web-development puzzle that Microsoft is trying to emulate. That's great, and good luck to them, but my recent efforts with trying to use Entity Framework suggest that this may not be a viable solution for a long time to come.

I'm typing this to delay the effort of ripping EF out of my project, and do ADO.NET Linq-to-SQL. (I guess. Maybe it'll just be raw SQL at this point.) Unless someone here can answer this question? It's worth a shot... http://stackoverflow.com/questions/23528335/how-can-i-implem...

I miss Rails.

[df07]

Try Dapper for a simple .NET ORM. We created and use it for Stack Overflow. https://code.google.com/p/dapper-dot-net/

Here's the original post describing how we made it: http://samsaffron.com/archive/2011/03/30/How+I+learned+to+st...

[steverb]

Another plug for Dapper. I tell people it's an ORM for developers who aren't afraid of SQL. It doesn't hide the database, or force you to pretend it's not there. It excels at taking your rows of data and transmogrifying them to objects.

[daigoba66]

> transmogrifying

Also known as "mapping"; the literal purpose of an ORM. :)

Other big tools/frameworks include APIs for query generation, unit of work, caching, etc., which are not always necessary or desired.

[mmgutz]

Data mappers map tables to objects.

ORM's compensate for the impedance mismatch between objects and tables. They do a lot more than mapping.

[TheRealDunkirk]

THANK YOU for this link. It's extraordinarily on point for me. My boss went to the recent MSDN conference in Chicago, and he came away with the conclusion that we should not use it, so it may be out of my hands at this point. But your article is still awesome, and serves to illuminate exactly where the limitations lie.

[pauldbau]

You should definitely also check out ServiceStack. Dapper-like ORM, amazing web service capabilities and awesome serializers all in one place. Supports everything too (Mono, Xamarin etc).

[locusm]

Yup +1 for ServiceStack. Check out the project owners answers on StackOverflow.

[Xdes]

My VB is a bit rusty, but you will need to define associations in the configuration.

First add foreign keys to to models (e.g. In the Build class add MainlineID for the Mainline object).

Then you can define the configuration:

    Public Class BuildConfiguration
        Implements EntityTypeConfiguration(Of Build)

        Public Sub New()
            ToTable("Build")
            ' Other mappings
            ' Define one-to-many
            HasRequired(Function(x) x.Mainline) _
            .WithMany(Function(x) x.Builds) _
            .HasForeignKey(Function(x) x.MainlineID)
        End Sub
    End Class

Inside your context you load the configuration:

    Public Class MyContext
        Inherits DbContext

        Public Property Builds As DbSet(Of Build)

        Protected Overrides Sub OnModelCreating(modelBuilder As DbModelBuilder)
            MyBase.OnModelCreating(modelBuilder)
            modelBuilder.Configurations.Add(New BuildConfiguration())
        End Sub
    End Class

Then you can use the Include extension method (or eager loading) on the DbContext to populate the object.

    Using context As New MyContext()
        Return context.Builder.Include(Function(b) b.Mainline)
    End Using

See also:

http://weblogs.asp.net/manavi/archive/2011/05/17/association...

[TheRealDunkirk]

I had seen that linked writeup before, but was confused, because much of that code looked unnecessary for EF6. I relegated it to only being applicable to version 4. Indeed, all I needed to do (as below) was use .SelectMany(). That being said, though... Wow, your Fluent API-fu is strong.

[rpsw]

On the face of it, your query seems simple (in C#, should be easy to translate):

  var releases = db.Releases.Where(r => r.Build.Mainline.MainlineID == 4);

Or am I missing something?

[Gmo]

AFAIK, LINQ-To-SQL is deprecated. And I seen you already have a quality answer here and on stackoverflow to your question.

EF has its fair share of issues and limitations, but that's not one of them.

[Pxtl]

Imho, that's one of MS' big problems. They create tools at a terrifying rate and are very hesitant to warn users about deprecations.

The modern C# stack can be very pleasant, but it's in an ocean of horrible mistakes and dead-ends that they can't flag as such for marketing reasons.

[TheRealDunkirk]

Well, crud. OK. Thanks for the warning. <hangs head/>

[Pxtl]

EF is nearly the same. Really, the Linq-to-SQL story is embarrassing - it was released in .NET 3.5, and deprecated in .NET 3.5 sp1 when they released the first public version of Entity Framework... which was so horribly bad that it was barely usable.

.NET 4 made EF good, but 3.5 was a mess.

[NicoJuicy]

I actually develop everything in EF first, if we need to continue the project further, i'll integrate a DDD-pattern. If the app is going slow, i'll switch EF with Dapper. For Db hogs, i use Stored Procedures with the SqlQuery on the DataContext

Although many use nhibernate instead of EF, i have no experience with it... (it's more db agnostic though).

I'm not sure, but i wouldn't advice Linq To SQL though...

[DougWebb]

My company built our own ORM; it predates Entity Framework and other alternatives being viable. Recently we considered whether it's worthwhile to continue maintaining our own ORM or if we should switch. As part of the investigation our CTO spoke with a roundtable group at the Microsoft Build conference, and the consensus was that EF was not mature enough to meet our needs. This came from some people who are involved with developing EF.

In the end, we decided to continue to maintain and enhance our own ORM, because of the special features it has to support the Enterprise niches we work with. But if we had to start over fresh today, we'd definitely avoid EF and we'd probably build upon NHibernate. As far as we could tell, NHibernate had the most mature features and ability to support the market we're in.

[daigoba66]

At present, NHibernate has more features than EF and is quite stable. Although EF does have a much better LINQ provider if that's your sort of thing. Check out http://lostechies.com/jimmybogard/2014/04/22/migrating-from-....

[Swinx43]

I have never been a fan of EF, mainly because my background is more on the database side. That said it has its place but to do everything blanket EF is not always a good idea.

[kr4]

You should use .SelectMany along with .Where (not .Find). I can see an answer on SO that just does this.

[TheRealDunkirk]

You're dead on. This was the missing link for me. I'd seen .SelectMany() in examples of self-referential tables, but not as the main tool to traverse sub-child relationships.

[adamdavis]

Good luck with that. For what its worth, in my experience, I've found .NET development to be less painful when not using Entity Framework.

[NicoJuicy]

For some things, EF can be paintfull, but i'd just use SQL queries instead if it takes to long.