Paul Kimmel's Blog

As an old SQL junkie, I have not tried LINQ. Can you entice me with some nice benefits of using LINQ, and how I can leverage these with DevExpress components? (any WOW factors?).

I thought you DX'ers hated EF! :)

I am in the process of rewriting an unreleased product migrating from XPO to EF. EF  just gives me capabilities (nTier/WCF) that XPO did not handle as well as I would have liked. Excited to see your book!

Denny, check back. I will be posting some harder technical articles over the course of the next several days. Keep in mind that LINQ to SQL is just one use of LINQ. LINQ can go where SQL really isn't meant to go like objects, XML, Active Directory, and probably sharepoint and other SQL-based provider languages too.

Nate:

I don't hate EF. As far as I know no one has told me what to like or not like. I am working on an EF book. Some times its hard to tell the truth, but no (at Microsoft either) says--you can't talk about that.

I think data access layers are hard, which is why everyone does their own. Its time the language providers--Microsoft or Sun--solve this. Its to unproductive to roll your own. We have some great stuff like XPO. Personally, I am a right tool for the job kind of guy. (Thanks about teh book reference.)

I personally would rather like to see posts about LINQ to XPO, because no one from the Framework team does.

@Robert.. i concur: it seems odd to see EF being promoted here.

I agree with Robert, I vote for LINQ to XPO posts, DX should help us better understand their controls and frameworks...

"...don't spend a lot of brain cycles on eSQL, and don't bet the farm, your reputation, or your job on the Entity Framework just yet."

As Robert, Drew, and Norbert have indicated, I think you'll find most people that read these blogs have already "bet the farm" on XPO, XAF and supporting DevEx tools. Personally I am only interested in DevEx progress toward making these tools better and posts that promote a deeper understanding about how to use them. My entire business is invested in them.

Side Note: Contrats on the book deals, quite an accomplishment!

I just starting XAF and have been using XPO on our State projects.  I agree with Linton that we need to support the DevEx progress because many out there like myself push for you guys.  We were fortunate enough to get the State of Texas to buy 20 licenses from DevEx and I hope to show them more of what your tools can do for them.

I think LINQ is revolutionary but am getting the feeling DevEx seems to shy away from it in certain cases.

In particular I am having huge problems trying to get an editable ASPxGridView to work with LINQ because of the callback mechanism that the grids use. The problem is the fact that ViewState is not updated between callbacks and so when you try to edit a record you just added to a grid, LINQ kicks back an error saying it cannot find a record with matching rows to update.

In addition I had to completely turn off the concurrency checking that LINQ provides (using a TimeStamp field) because it wouldn't work at all editing and trying to save existing records with a gridview. Again all the problems seem to revolve around callbacks.

I asked for support on these issues and felt like I didn't get a straight answer. What I wanted to know was, is it impossible to use an ASPxGridView in callback mode with LINQ, or are there changes that can be made to the gridview that would allow it to work? Or, something in my code that I can do to fully utilize LINQ while still using callbacks?

P.S. Thanks for the blog, I'm looking forward to future posts!

Rob, I use ASPxGridView with callbacks and LinqDataSources and LinqServerModeDataSources all day, every day with no problems... I have seen that error, but I think you need to set enablerowscache=false on the grid, or more importantly, on your LinqDataSource set storeoriginalvaluesinviewstate=false... I am surprised support has not pointed you to a few resources.

Troy, thanks for the comments! Maybe we should move this discussion to a community forum?

In any case, if I have these settings: EnableRowsCache=false, StoreOriginalValuesInViewState=false, have a timestamp field on the table and have specified such in the datacontext, consistently yields the error "Row Not Found Or Changed" whenever trying to modify any record in the table using the gridview. If I re-enable StoreOriginalValues, it works. However I don't want to store values in the viewstate as a large table could yield a large viewstate.

From what I've read, what is "supposed" to happen under normal circumstances is that by setting a timestamp field in the table, LINQ will use that field and only that field to determine of a row was changed before allowing the update (concurrency control). It will automatically use the key field in the table to locate the row to check the timestamp. This should happen regardless of ViewState usage.

I noticed the problem I had with callbacks (described above) goes away if I turn EnableRowsCache off per your suggestion.

I don't know why I have to use ViewState to get the grid to work properly with LINQ, documentation I've read doesn't seem to indicate it's required!

Great article, I have the same feelings about EF.

As a side note, I agree with Linton, another one here that "bet the farm, and reputation" on XPO. My entire line of business applications is made using XPO. Hope to see more focus on this in 2009.

Paul do you have a favorite iteration that you use with LINQ?  I have found the iterations to be very helpful within my application even when I am not directly working with a SQL back-end.

LINQ is a very powerful item to have in our toolkits.

Interesting article.

As another XPO user, I would like some guidance as to the future of XPO and LINQ EF.

Should I be planning to migrate existing or cancel new XPO development?

Will DexExpress present XPO benefits that are available along with the use of LINQ EF?  Or is XPO now redundant?

Best regards,

Kervin

@Kervin: no, XPO is not redundant, and no, you should not cancel XPO development.

@Paul: Kervin's confusion is a typical outcome of such a blog post. Evangelists should not confuse, but clarify things.

IMHO.

Is LINQ to SQL faster than ADO.NET?

Thanks.

I think EF is a relevant topic for discussion since it is something DX will need to support. Their customers will use it just like they use XPO. It is just one of many tools at our disposal. I’ve long given up on XPO for one reason or another. I don’t think EF is worth anything at this point, but it isn’t going away and we shouldn’t ignore it. I personally didn’t find this post confusing. I don’t think a lot of people buy DX controls just to get XPO (maybe a few). I am getting my monies worth just from the win/web form controls. Besides, XPO already has its own Evangelists and they seem to be doing a good job. I don’t think it would hurt to read something different. Maybe to avoid any confusing for those who are uncertain, Paul should include a disclaimer.