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.Entity<Person>()
.HasKey(p => p.PersonId);
// Person - Firstname DB rules.
modelBuilder.Entity<Person>()
.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 <[email protected]>wrote:
> 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
> <[email protected]>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, <[email protected]> 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
>
>
