6 ms·

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 t

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-implement-a-rails-like-has-many-through-in-entity-framework http://stackoverflow.com/questions/23528335/how-can-i-implem... I miss Rails.

kr4 12y ago
You should use .SelectMany along with .Where (not .Find). I can see an answer on SO that just does this.
- TheRealDunkirk 12y ago
  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 12y ago
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 12y ago
  For some things, EF can be paintfull, but i'd just use SQL queries instead if it takes to long.
Swinx43 12y ago
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.
df07 12y ago
Try Dapper for a simple .NET ORM. We created and use it for Stack Overflow. https://code.google.com/p/dapper-dot-net/ 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+stop+worrying+and+write+my+own+ORM http://samsaffron.com/archive/2011/03/30/How+I+learned+to+st...
- steverb 12y ago
  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 12y ago
    > 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 12y ago
      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 12y ago
  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 12y ago
    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).
rpsw 12y ago
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?
Xdes 12y ago
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/associations-in-ef-4-1-code-first-part-6-many-valued-associations.aspx http://weblogs.asp.net/manavi/archive/2011/05/17/association...
- TheRealDunkirk 12y ago
  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.
DougWebb 12y ago
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 12y ago
  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-nhibernate-to-entity-framework/ http://lostechies.com/jimmybogard/2014/04/22/migrating-from-....
Gmo 12y ago
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.
- TheRealDunkirk 12y ago
  Well, crud. OK. Thanks for the warning. <hangs head/>
  - Pxtl 12y ago
    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.
- Pxtl 12y ago
  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.
NicoJuicy 12y ago
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...

kr4 12y ago

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

TheRealDunkirk 12y ago
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 12y ago

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 12y ago
For some things, EF can be paintfull, but i'd just use SQL queries instead if it takes to long.

Swinx43 12y ago

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.

df07 12y ago

Try Dapper for a simple .NET ORM. We created and use it for Stack Overflow. https://code.google.com/p/dapper-dot-net/ 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+stop+worrying+and+write+my+own+ORM http://samsaffron.com/archive/2011/03/30/How+I+learned+to+st...

steverb 12y ago
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 12y ago
  > 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 12y ago
    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 12y ago
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 12y ago
  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).

rpsw 12y ago

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?

Xdes 12y ago

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/associations-in-ef-4-1-code-first-part-6-many-valued-associations.aspx http://weblogs.asp.net/manavi/archive/2011/05/17/association...

TheRealDunkirk 12y ago
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.

DougWebb 12y ago

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 12y ago
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-nhibernate-to-entity-framework/ http://lostechies.com/jimmybogard/2014/04/22/migrating-from-....

Gmo 12y ago

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.

TheRealDunkirk 12y ago
Well, crud. OK. Thanks for the warning. <hangs head/>
- Pxtl 12y ago
  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.
Pxtl 12y ago
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.

NicoJuicy 12y ago

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...