Re: Dump EntityFramework for LLBLGen
Nope, it was mostly annoying as it wouldn't respect shared POCO libraries, that is to say the proxy generator itself would extend those classes instead of just resolving them as-is ... so if you had a client and server all pulling the same DLL for the entity objects, it wouldn't work as cleanly. You then had to write a DataContract resolver on your own to handle the lookups to ensure you had one DAL to rule them all. That and I find most code-gen solutions from MSFT team to be too mickey mouse, despite my repeated warnings that they should stop this foolishness. --- Regards, Scott Barnes http://www.riagenic.com On Sat, Apr 14, 2012 at 7:28 PM, Greg Keogh g...@mira.net wrote: ie I've written a small code-gen tool that basically will inspect a basic POCO and then spit out some code that produces something like this inside my DbContext class. ** ** How do you feel about the EF 4.x POCO Entity Generator? Didn’t it suit your needs? ** ** I’ve only used the Self-Tracking template, not the POCO one. However, out of curiosity I just generated some code with the POCO template to see what it looks like, and it’s pretty “plain” with no dependencies upon anything in System.Data. ** ** Greg
Re: Dump EntityFramework for LLBLGen
David, That's interesting - I'm working on a fairly large in production app using EF at the moment. We're not using POCO and currently have 259 tables in the EDMX. What's the magic number that you ran into? I also must admit that I agree with a lot of the things that Scott and some of the other posters have said. While EF does generate some quite interesting SQL under the covers the majority of the time it has been reasonable enough for our purposes. For the times that it hasn't we have custom rolled a few stored procs to cover the issues. Neil. On 13 April 2012 18:53, djones...@gmail.com wrote: There are limitations to EF. A project here was started with ef but soon ran into obstacles when the number of tables mapped was greater than the number possible in ef. It's now using hand written dal that is a damn sight faster as well. EF / NHibernate are tools, use the right tool for the right job. Davy Hexed into a portable ouija board. From: Arjang Assadi arjang.ass...@gmail.com Sender: ozdotnet-boun...@ozdotnet.com Date: Fri, 13 Apr 2012 11:05:45 +1000 To: ozDotNetozdotnet@ozdotnet.com ReplyTo: ozDotNet ozdotnet@ozdotnet.com Subject: Re: Dump EntityFramework for LLBLGen One Word: EF Code First! and I haven't looked back ever since. DAL is dead, Long live Entities Regards Arjang On 13 April 2012 10:59, ifum...@gmail.com wrote: Been using llbLgen for years but finding that EF would do what i need. Would save me a step(time) using EF in vs 2010 instead of generate DAL using LLblgen Anyone have an opinion on this? Anthony
RE: Dump EntityFramework for LLBLGen
ie I've written a small code-gen tool that basically will inspect a basic POCO and then spit out some code that produces something like this inside my DbContext class. How do you feel about the EF 4.x POCO Entity Generator? Didn't it suit your needs? I've only used the Self-Tracking template, not the POCO one. However, out of curiosity I just generated some code with the POCO template to see what it looks like, and it's pretty plain with no dependencies upon anything in System.Data. Greg
Re: Dump EntityFramework for LLBLGen
There are limitations to EF. A project here was started with ef but soon ran into obstacles when the number of tables mapped was greater than the number possible in ef. It's now using hand written dal that is a damn sight faster as well. EF / NHibernate are tools, use the right tool for the right job. Davy Hexed into a portable ouija board. -Original Message- From: Arjang Assadi arjang.ass...@gmail.com Sender: ozdotnet-boun...@ozdotnet.com Date: Fri, 13 Apr 2012 11:05:45 To: ozDotNetozdotnet@ozdotnet.com Reply-To: ozDotNet ozdotnet@ozdotnet.com Subject: Re: Dump EntityFramework for LLBLGen One Word: EF Code First! and I haven't looked back ever since. DAL is dead, Long live Entities Regards Arjang On 13 April 2012 10:59, ifum...@gmail.com wrote: Been using llbLgen for years but finding that EF would do what i need. * *** ** ** Would save me a step(time) using EF in vs 2010 instead of generate DAL using LLblgen ** ** Anyone have an opinion on this? ** ** ** ** Anthony
Dump EntityFramework for LLBLGen
Been using llbLgen for years but finding that EF would do what i need. Would save me a step(time) using EF in vs 2010 instead of generate DAL using LLblgen Anyone have an opinion on this? Anthony
Re: Dump EntityFramework for LLBLGen
One Word: EF Code First! and I haven't looked back ever since. DAL is dead, Long live Entities Regards Arjang On 13 April 2012 10:59, ifum...@gmail.com wrote: Been using llbLgen for years but finding that EF would do what i need. * *** ** ** Would save me a step(time) using EF in vs 2010 instead of generate DAL using LLblgen ** ** Anyone have an opinion on this? ** ** ** ** Anthony
RE: Dump EntityFramework for LLBLGen
What about disconnected scenarios... I currently able to serialize(using LLBLGEN) an entity(or entity collection) from a web service and pass it to a client to be de-serialized very easily, can EF do this without much hassle? From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Arjang Assadi Sent: Friday, 13 April 2012 11:06 AM To: ozDotNet Subject: Re: Dump EntityFramework for LLBLGen One Word: EF Code First! and I haven't looked back ever since. DAL is dead, Long live Entities Regards Arjang On 13 April 2012 10:59, ifum...@gmail.com wrote: Been using llbLgen for years but finding that EF would do what i need. Would save me a step(time) using EF in vs 2010 instead of generate DAL using LLblgen Anyone have an opinion on this? Anthony
Re: Dump EntityFramework for LLBLGen
Try doing that on a PDA (aka smartphone). DAL is by no means dead. David If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate! -Zapp Brannigan, Futurama On Fri, Apr 13, 2012 at 11:05, Arjang Assadi arjang.ass...@gmail.com wrote: One Word: EF Code First! and I haven't looked back ever since. DAL is dead, Long live Entities Regards Arjang On 13 April 2012 10:59, ifum...@gmail.com wrote: Been using llbLgen for years but finding that EF would do what i need. Would save me a step(time) using EF in vs 2010 instead of generate DAL using LLblgen Anyone have an opinion on this? Anthony
Re: Dump EntityFramework for LLBLGen
My experiences with entity framework have been far from universally positive. Code first I find slightly discomforting from the get-go because of the plethora of attributes that end up on your model (especially when used in conjunction with ASP.NET MVC... ) everything from the UI to persistence ends up getting glued on to your model and this is somehow OK becuase it is done with attributes? EF keeps getting better with each release, but that is faint praise. In 4.5 they allowed pre-compilation of query expressions, which had previously limited performance of one project I know of to about 5 concurrent users before the CPUs melted through the case. In 4.5 they also apparently fixed bugs like this http://stackoverflow.com/questions/682429/how-can-i-query-for-null-values-in-entity-framework The biggest problem I've seen with EF is the performance. Have a look at some of the queries it generates to do simple-seeming selects and then ponder how you would go about tuning said query. At the end of the day EF seems like a really leaky abstraction over database access. It can work if you're constantly looking 'under the covers' at the SQL it generates, and are prepared to constantly think about how you need to structure a particular linq expression or API call to work with EF, but it has always felt to me like it causes more problems than it solves. Joseph On Fri, Apr 13, 2012 at 11:05 AM, Arjang Assadi arjang.ass...@gmail.comwrote: One Word: EF Code First! and I haven't looked back ever since. DAL is dead, Long live Entities Regards Arjang On 13 April 2012 10:59, ifum...@gmail.com wrote: Been using llbLgen for years but finding that EF would do what i need. ** ** Would save me a step(time) using EF in vs 2010 instead of generate DAL using LLblgen ** ** Anyone have an opinion on this? ** ** ** ** Anthony -- w: http://jcooney.net t: @josephcooney
Re: Dump EntityFramework for LLBLGen
I agree with what Joseph says ...yet, i need to add a but :)
I've spent close to the past 8 months writing an Enterprise Service Bus
(yeah, I must be the only one right?) from the ground up. I've got a lot of
unique constraints that I'd argue most LOB solutions haven't had to face.
Firstly, bandwidth is a huge issue given the solution I've produce has to
be deployed on some Panasonic Tough Books that are used in the middle of
Central Queenslands coal fields combined with occasionally connected 3G
capabilities.
The secondary issue is around the volumes of data that are collected, in
that if you take a Geologist on an average day and how much data they
interact with it can easily climb into the 100's of gigs all whilst living
on a combination of LAN vs 3G connections as its transport protocol.
The last is WPF... i think we can leave that one alone though ;), jokes
aside the last is also co-worker or developer maturity. I can't hire all of
you rockstars here on this list, and times have to produce a solution that
is going to range from a Junior to Principle developer skillset.
Ergo, my strategy around usage of EF resides on two things. The first is
that it's palatable to most developers in its usage from an API stand
point, despite numerous twitter outbursts and moments of quit rage boiling
over throughout, it however does solve a need in that space.
It also via code-first option provides an easy win around abstraction or
more to the point don't think persistence but it comes with a catch
(which I think Joseph is eluding to). If you use it from a RDBMS stand
point with a code-first mentality you're basically going to get schooled
just by how badly Microsoft code-generation or automated frameworks can be.
However, if you approach it from a NOSQL approach with a code-first option
you very well may stand a chance to survive.
Vis a Vi, Concordantly - EF can hold a place around how you persist data
from a UI top down strategy, that is to say if you design your data object
graphs from UI perspective you can get away with some happy wins. Whilst
also combining this with DDD/CQS/MSMQ blah blah, you can also get some wins
as well as what you're effectively doing is breaking the various return
trips to getting data based of small data snacking principles.
For large data sets however in terms of Gimme all data that has the number
0 in it, I've instead gone down the path of using a REST WCF Data Services
approach, which admittedly is still not a cheapest way to handle this kind
of thing but at the same time sending gigabytes of data to a client on a
call by call basis in my context is an overkill. I prefer to use other
transport methods to handle larger data sets (which even at times uses
FTP/WebDAV).
You can also abstract your POCO/TO/BO's etc from EF without having to
decorate them with attributes, it just is easy to just quickly use [Key]
inside the object instead of parking that via Fluent style declarations in
your DbContext classe(s)
ie I've written a small code-gen tool that basically will inspect a basic
POCO and then spit out some code that produces something like this inside
my DbContext class.
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
// Person - Primary Key.
modelBuilder.EntityPerson()
.HasKey(p = p.PersonId);
// Person - Firstname DB rules.
modelBuilder.EntityPerson()
.Property(p = p.Firstname)
.HasColumnName(fstname)
.IsRequired()
.HasMaxLength(50);
base.OnModelCreating(modelBuilder);
}
Inside a separate project which has no EF dependencies at all (pure ye olde
C# project)
[Serializable]
public class Person : IPerson
{
public Person()
{
this.PersonId = Guid.NewGuid();
}
public string Prefix { get; set; }
#region IPerson Members
public Guid PersonId { get; set; }
public string Firstname { get; set; }
public string Lastname { get; set; }
public string Alias { get; set; }
#endregion
}
public interface IPerson
{
Guid PersonId { get; set; }
string Firstname { get; set; }
string Lastname { get; set; }
string Alias { get; set; }
}
Now, some of you are likely to groan and shake a fist or two at this
strategy but i'd rather tell a developer you are going to have to use
those fingers on the keyboard an extra 10mins or so more than tab-dot-ship
approach you're probably used to, but ...suck it up. As i'd rather have
code-gen tools that automate knuckle head typing issues than ones that
bleed into my .NET composition creating performance related issues.oh
wait... ..EF...never mind :)
So neh! :)
---
Regards,
Scott Barnes
http://www.riagenic.com
On Fri, Apr 13, 2012 at 1:06 PM, Joseph Cooney joseph.coo...@gmail.comwrote:
My experiences with entity framework have
