tag:blogger.com,1999:blog-6393051114813114443.post9028756384532672648..comments2024-03-27T14:52:51.318-05:00Comments on Lee's Blog: Death to the DAO and How to Test LINQLee Richardsonhttp://www.blogger.com/profile/01314803491511307042noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-6393051114813114443.post-76561773812204178272010-07-29T09:20:53.444-05:002010-07-29T09:20:53.444-05:00This isn't really a huge change though. I mean...This isn't really a huge change though. I mean you still have to implement the static class for the extensions, and that's almost like any old repository... Also, the objects that come directly from the hopper are bound to the change events and the context so you have to stomp on them accordingly if you want to do a lot of 'normal' things. This is not to mention the lack of serializability of the stuff you get from most LINQ to X (again because of the context dependancy.) The easy way around all of that is to .. encapsulate them inside DAOs that produce POCOs, and translate them back again. Even using the new extensions to EF that allow POCO integration, you're really not 'removing a layer' like you'd think, you're just moving everything into the same project file. Potato - Pototo. Different yes, somewhat shorter in simple cases, sure. Huge revolutionary new feature and less code? No, not really.dave.dolannoreply@blogger.comtag:blogger.com,1999:blog-6393051114813114443.post-48851678761805433412010-07-29T09:04:05.865-05:002010-07-29T09:04:05.865-05:00Erlis Vidal,
Thanks, that's a great example a...Erlis Vidal,<br /><br />Thanks, that's a great example and now I see what Dmitriy meant. I guess that's an issue specific to the EF. LINQ to SharePoint fails over to LINQ to Objects if it can't convert something to CAML, so performance may be bad, but you'd never have a problem where your unit tests work, but your production code wouldn't. <br /><br />Regardless you're absolutely right this technique is not a replacement for integraiton tests.<br /><br />- LeeLee Richardsonhttps://www.blogger.com/profile/01314803491511307042noreply@blogger.comtag:blogger.com,1999:blog-6393051114813114443.post-85797017987274805412010-07-29T08:40:40.399-05:002010-07-29T08:40:40.399-05:00Hi Lee,
You asked Dmitriy for an example that do...Hi Lee, <br /><br />You asked Dmitriy for an example that doesn't work. I have one for you. <br /><br />If using EF with MySql (this was what I used) you call .SingleOrDefault() you will have an error, you must use FirstOrDefault()<br /><br />This will work beautiful in your tests because Linq to Object will simply accept .SingleOrDefault and you will only notice this on production. That's why some integration tests are needed also. <br /><br />--ErlisErlis Vidalhttps://www.blogger.com/profile/06011037470148116038noreply@blogger.comtag:blogger.com,1999:blog-6393051114813114443.post-4488741757157735722010-07-27T13:23:27.591-05:002010-07-27T13:23:27.591-05:00@Anonymous Thanks, fixed the link. Actually I fou...@Anonymous Thanks, fixed the link. Actually I found a second post by him which includes more detail so I linked to that too.Lee Richardsonhttps://www.blogger.com/profile/01314803491511307042noreply@blogger.comtag:blogger.com,1999:blog-6393051114813114443.post-30912696076798762010-07-27T13:07:28.121-05:002010-07-27T13:07:28.121-05:00Your link to Daniel Cazzulino's post is broken...Your link to Daniel Cazzulino's post is broken. Would you mind updating it? I'd love to read it to get more context for your comparison.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6393051114813114443.post-47675141144774019902010-07-27T09:57:40.001-05:002010-07-27T09:57:40.001-05:00@Dmitriy
1. You can handle this the same way you...@Dmitriy <br /><br />1. You can handle this the same way you handle inserts and updates (InsertOnDelete etc) which is, when necessary, to encapsulate the "Employees" item off of context and have a Fake for your tests that ignores the preload instructions and implements the inserts, updates, and deletes for in-memory objects. I was going to write about this in a future post, but that's the gist of it.<br /><br />2. I'd like to see an example of what doesn't work. This approach is working well for me, but I don't use the EF.<br /><br />3. Yes failing to organize your extension methods would be a terrible idea. Fortunately I group mine by Entity.Lee Richardsonhttps://www.blogger.com/profile/01314803491511307042noreply@blogger.comtag:blogger.com,1999:blog-6393051114813114443.post-18849639330035028502010-07-27T09:45:41.779-05:002010-07-27T09:45:41.779-05:00You'd better use Repository pattern. I don'...You'd better use Repository pattern. I don't like DAO objects. When using a repostiroy, you have an interface which you can easily mock.Boyan Mihailovhttps://www.blogger.com/profile/14646392106570279580noreply@blogger.comtag:blogger.com,1999:blog-6393051114813114443.post-834487006785882612010-07-27T08:48:08.066-05:002010-07-27T08:48:08.066-05:00Two main problems here from top of my head:
1. Imp...Two main problems here from top of my head:<br />1. Impossible to preload related objects and optimise query with query options and fetch plans.<br />2. In many non-trivial cases LINQ extensions with the fake queryable collection (LINQ to Objects) will work, but when running application will fail because the context is different and is not supported/implemented (EF). This draws such tests useless and harmful.<br /><br />This is not different from having a bunch of static methods in a large bin (which often becomes rubbish one). Anything gets thrown into it.<br /><br />Ragards,<br />Dmitriy.Dmytriihttps://www.blogger.com/profile/00858741986129879076noreply@blogger.com