Today Scott “The Dot Glue” is hyping AND spinning EF CTP 5 on his blog. Instead of my personal rants about how bad EF is, let’s take DOT Glue’s own example code and rip it to shreds with” code first” and see the future and the past to determine if we are really better off by comparing the EF to VFP.
After all “Source Code Doesn’t Lie”…
The Entity Framework CTP 5
Step 1 Model Class and DB Context classes.
Actually we have to build up the tables first, just a minor detail...
So let’s see what these model classes look like...
Public class Product
{
Public int productid { get; set }
Public int categoryid { get; set }
Public string productname { get; set }
// WTF is up with the ? talk about an after thought…
Public Decimal? UnitPrice { get; set }
Public Bool Discontinued { get; set }
public virtual category category { get; set }
}
Now we have to jerk with the category table class
Public class category
{
Public int categoryid { get; set }
Public string categoryname { get; set }
Public string description { get; set }
public virtual ICollection
}
Public virtual is one of the bullshit commands that Microsoft loves since it struggles to do anything that is straightforward in Visual Studio. Basically we have two tables or collections, products and categories and there is a relationship between the two that is lazy loaded so EF needs a property for some screwy reason.
Now we need to create a data context – No I am not shitting you
Public class northwind : dbcontext
{
public dbset Product {get;set;}
public dbset Category {get;set;}
}
Side note: You need less then and greater than signs around the table names. The blogger editor stripped them out.
Thanks goodness THE GLUE doesn’t use any real world examples I would spend hours hand coding the classes.
Step 2 Configure the connection string
No big surprise a connection string in the app.config, if vfp was accessing a sql database we issue a sqlconnect no biggie either way.
Security=SSPI;AttachDBFilename=|DataDirectory|\northwind.mdf;
User Instance=true"
providerName="System.Data.SqlClient" />
Step 3 Pull a collection from EF
DOT GLUE used linq in this example
Personally I hate the linq syntax it is sort of like reinventing the wheel and building a CUBE instead of a circle.
NorthWind Northwindw() = new NorthWind();
var p = from p in northwind.products
where p.category.categoryname = “Beverages”
select p;
Step 4 an EF update
NorthWind Northwind() = new NorthWind();
Product.Product = northwind.products.find(1);
Product.UnitPrice = 2.33m;
Product.Discontinued = false;
// this is where the VS Cheerleaders have an orgasm and praise gu!
Northwind.SaveChanges();
NOW Let’s run through this same example in VFP
Yes no class code or data context required.
For humor sake if we wanted a record object it would look something like this.
Select product
Scatter name oProduct blank
Select category
Scatter name oCategory blank
Yes that is correct in Visual FoxPro we use two lines of code no cryptic syntax no virtual relationship command. Even more important if the base tables structure changes no change is required to the code.
Next The Glue built a collection using linq… a cursor will work just fine in vfp.
Select * from products
inner join category on products.categoryid = category.categoryid
where categoryname = “Beverages” into cursor p
That looks familiar Native SQL in VFP sweet! Yes the same syntax can be executed against a sql database using sqlexec. This is important makes sure you read my closing comments with regards to sql commands and ef!
Perform an Update
Select product
= seek(1) // This finds a record
Don’t even complain about what happens if the record is not found THE GLUE didn’t handle that case either. Yes we could add the workarea and index into the seek command and use one line of code instead of two.
Scatter name oProduct
oProduct.UnitPrice = 2.33m;
oProduct.Discontinued = false;
// this is where VFP developers should be laughing at EF as we have been saving records with one line of code since foxpro for dos.
Gather name oProduct
Is it just me or are you having a WTF moment as well.
Folks Microsoft killed Visual FoxPro and now we have the entity framework don’t you love progress Microsoft Visual Studio style!
EF Validation
Next THE GLUE blogs about two property attributes: range and required. My first instinct when I read this was that is pretty cool. Then I sat back any thought about it for a minute and SAID this is bullshit and here is why.
If there is a UI involved the range and required validation should occur in the form! Now you are thinking yeah Mark you missed the case of a web-service and reusability. Fair enough but wouldn’t it be better to catch this in the business layer object of the middle tier and avoid a round trip to the server and connecting to the datasource etc- after all you die hard performance based MVC guys are worried about view state in the HTML being downloaded from the server slowing things down you should crap yourself if you have to load the EF data context when it isn’t needed.
Ironically in the next paragraph THE GLUE discusses Keeping things DRY
The “DRY Principle” stands for “Do Not Repeat Yourself".
Don’t you wish Microsoft came up with this idea with regards to the .NET FRAMEWORK that is all redundancy or how about 6 different Datagrids and list views and isn’t there two different View Engines for MVC. Better yet how about all the different flavors of Vista ... What an Joke!
The GLUE wraps this post up by getting us excited about other improvements
1) EF Code First CTP5 exposes a new set of change tracking information that enables you to access Original, Current & Stored values, and State (e.g. Added, Unchanged, Modified, Deleted). This support is useful in a variety of scenarios.
Well this sounds like VFP GetNextModified and GetFldState to me nothing new there.
2) EF Code First CTP5 now allows raw SQL queries and commands (including SPROCs) to be executed via the SqlQuery and SqlCommand methods exposed off of the DbContext.Database property. The results of these method calls can be materialized into object instances that can be optionally change-tracked by the DbContext. This is useful for a variety of advanced scenarios.
By advanced scenarios does THE GLUE mean cases that Linq to entities can’t handle or does linq to entities perform so poorly under some instances you really should use an SPROC? Regardless this was available years ago in VFP in the native VFP SQL statement and does SQLEXEC sound familiar to VFP developers?
THE GLUE writes in conclusion, EF Code First provides an elegant and powerful way to work with data [OBVIOUSLY HE NEVER USED A DATA CENTRIC LANGUAGE BEFORE LIKE VFP]. I [“THE GLUE”] really like it because it is extremely clean and supports best practices [IS THERE REALLY SUCH A THING AT MICROSOFT AS BEST PRACTICES WHEN TECHNOLOGY AND PARADIGMS ALMOST CHANGE DAILY?], while also enabling solutions to be implemented very, very rapidly [THIS HAS TO BE A TYPO]. The code-only [HE NAILED THAT ONE THERE IS A TON OF CODE IN VISUAL STUDIO APPLICATION DEVELOPMENT AND NOT MUCH RAD] approach of the library means that model layers end up being flexible and easy to customize….. [OH REALLY WE MAKE A CHANGE TO A DATA STRUCTURE AND LETS SEE WE NEED TO RECOMPILE THE EF AND CHANGE ALL THE CLASSES REAL FREAKING EASY]
I think it would behoove THE GLUE to use VFP for a while before writing a blog post as according to my blog post there is nothing new or elegant based on the sample code Scott GU is blogging about when using the Entity Framework. Obviously VFP should be the winner but even if you want to give the THE GLUE the benefit of the doubt, look there is not a thing in this example that is new or different at best this example is on par with VFP technology.
The funny part is the GU is getting praised on his blog for EF when it is doing nothing but causing more work and I am sure a few cheerleaders will flame me for pointing out just how bad the new EF technology really is…. And here I am trying to make their jobs easier by suggesting Microsoft builds (for you anyway - I went open source for all new web projects) development tools that work!
When all is said and done aren’t you glad source code doesn’t lie!
Until Next Time
Happy Coding!
.Mark
By the way in case you are interested here is the link to the no confidence petition for the entity framework started by several MVPS.
http://msmvps.com/blogs/peterritchie/archive/2008/06/25/entity-framework-petition-of-vote-of-non-confidence.aspx
8 comments:
Entity Framework sucks we used it in our application - it turned into a mess. EF's a hassle to deal with and unstable. This is a FAD and it too will pass.
@Mark, Your post comparing Visual Studio and Visual Fox are great! You should've mentioned the DBC where default field values, relationships and constraints can be established. IMHO business and data middle tier classes are the way to go.
Excuse me, I just have to say, I love this blog.
I really enjoy these comparisons, primarily because I don't have any of the problems these MS bandwagon products purport to solve.
That's because I use a mature and stable data-centric development tool that rocks. This tool isn't changing at the whim of some idiot schmuck who works at Microsoft.
Did you know that, if you are Microsoft, you can purchase the unwavering publishing loyalty of people simply by saying "you're an MVP" and "here's a subscription to our shit" that costs MS $150 per year tops per MVP.
Everyone has a price. Some folks' pretty low.
Keep up the great work.
Hey Steven and Sean,
Thanks for the comments, always appreciated!
@Steven, You are exactly right with regards to the VS mvp (cheerleader) network, it is nonsense.
I'm not going to mention names but I can't believe some of the crap recognized VFP developers are now spewing about the greatness of VS and .BLOAT. Talk about a contradiction.
Regards,
Mark
Nice.
Yeah, the EF has some issues in my testing....latency and the whole lazy-loading stuff gets weird.
However, I'm not sure it's comparable to VFP's way of doing things. The EF has a long, long way to go but so did Fox many moons ago.
Hey John,
I agree it is not totally comparable. I was trying to compare Scott's sample code and some comments in his blog to VFP perhaps I didn't make that clear.
I only have one client that I do some work for that implemented EF and it is an early version. It is a complete pain to work with besides some performance problems and compatibility issues, reporting comes to mind as one.
I can't figure out a scenario where it would be productive to use EF?
I have a feeling there is something else behind the move to EF for Microsoft then what they are stating. Maybe to tie applications into SQL Server as you know it has to torque Microsoft off when .net apps are tied into MYSQL or cloud related who knows.
Anyway thanks for the comments.
Mark
Hi Mark, your blog is really great. I never write, but I want you to know that I'm one of your "hidden" readers!
Thanks for so big fun and info! :)
fdbozzo,
Thanks for the comments, glad you like the blog.
Have a happy holiday.
Mark
Post a Comment