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