Mocks Nix - An Extensible LINQ to SQL DataContext

re: Mocks Nix - An Extensible LINQ to SQL DataContext

Davin — Mon, 05 May 2008 11:48:30 GMT

How does this work with generated code? Or are you suggesting that you would generate the code from the dbml and then replace DataContext with this ExtensibleDataContext?

Mocks Nix - An Extensible LINQ to SQL DataContext

LINQ in Action roller — Mon, 05 May 2008 13:10:36 GMT

I often get asked how LINQ to SQL is supposed to be used with Test Driven Design (TDD). Okay, not really.

re: Mocks Nix - An Extensible LINQ to SQL DataContext

Jeff LeBert — Mon, 05 May 2008 19:23:57 GMT

Another solution would be to use Typemock Isolator at http://www.typemock.com. There's a free community edition you can play with.

This allows you to mock almost anything including private and static methods. I've been using it for the last month on a C# application that was NOT designed to be unit tested. It's allowed me to test stuff that was impossible to test before without spinning up huge amounts of "state" just to test a simple thing.

This is a great hack and well worth the read. I believe it is the basis for the other mock frameworks like Rhino Mocks and MoQ.

LINQ to SQL Tips 3: Deferred (lazy) loading of related objects with stored procs

Dinesh's Cyberstation — Tue, 06 May 2008 09:13:22 GMT

This post is a confluence of two distinct sets of comments I got: The above-mentioned feature is a well-hidden

re: Mocks Nix - An Extensible LINQ to SQL DataContext

kfarmer@microsoft.com — Wed, 07 May 2008 00:07:37 GMT

Matt.. I'll say it: You craaazy, man.

By the way, what *are* the security principle requirements for this trick to work? Should we expect it to work in a web hosting scenario?

re: Mocks Nix - An Extensible LINQ to SQL DataContext

mattwar — Wed, 07 May 2008 18:15:42 GMT

Keith, I'm using reflection to overwrite a private field. You do the math.

re: Mocks Nix - An Extensible LINQ to SQL DataContext

James Hancock — Fri, 09 May 2008 02:20:18 GMT

Here's what I hope we get in V2 of Linq to SQL:

Full interfaces

Full Providers

A single file for each class that we can override and the designer doesn't screw with. It messes with Attributes and makes sure the stubs are right, and leaves the contents alone after it's been first implimented.

True OOP so that we can inherit classes and have the designer use them instead of the code gen crap.

True incremental change management instead of the entire file being ovewritten all of the time because of the designer.

Change Management at runtime for disconnected states (i.e. the object should store it's own changes and then deal with the context when it's added/updated to tell it what to update.

It should know which objects are modified and which aren't when added so that you don't have to just force it to update something that really hasn't changed.

Mocking LINQ to SQL

Mike Taulty's Blog — Fri, 09 May 2008 18:21:20 GMT

Matt Warren has an "interesting" post on how you could hack your way to a mocked implementation of LINQ...

re: Mocks Nix - An Extensible LINQ to SQL DataContext

Keith J. Farmer — Sun, 11 May 2008 21:35:52 GMT

@Matt: Yeah, that's what I thought. Just wanted to be sure about whether it was Cthulu or Leviathon you were invoking :)

re: Mocks Nix - An Extensible LINQ to SQL DataContext

Mike — Thu, 22 May 2008 11:44:01 GMT

"LINQ to SQL was actually designed to be host to more types of back-ends than just SQL server. It had a provider model targeted for RTM, but was disabled before the release. Don’t ask me why. Be satisfied to know that is was not a technical reason. Internally, it still behaves that way. The trick is to find out how to swap in a new one when everything from the language to the runtime wants to keep you from doing it."

That sounds scary. As a customer, I think I want to know why. How can I find out? Who should I ask, and should I expect an honest answer if the reason is not technical?

re: Mocks Nix - An Extensible LINQ to SQL DataContext

mattwar — Thu, 22 May 2008 18:38:59 GMT

Product decisions are made all the time that are not based on technical reasons. Often times it has to do with the balance of resources that can be put on the problem.

re: Mocks Nix - An Extensible LINQ to SQL DataContext

maxtoroq — Sun, 25 May 2008 00:17:48 GMT

What are the services we get for free from Linq to Sql by using this approach?

I'm guessing I have to translate Expression(s) to DbCommand(s) and DbDatareader(s) to Object(s), but what about Object Tracking?

re: Mocks Nix - An Extensible LINQ to SQL DataContext

mattwar — Sun, 25 May 2008 05:22:10 GMT

If you are 'mocking' the DataContext you are probably going to want to have it produce specific results depending on the cases you are testing and so you probably won't need to interpret the queries. I can imagine more advanced scenarios, however, writing code to handle these quickly becomes as complicated as writing a provider with its own query translator.

re: Mocks Nix - An Extensible LINQ to SQL DataContext

Fredrik K — Thu, 05 Jun 2008 15:31:42 GMT

I think you're going about this the wrong way. Instead of trying to mock the DataContext directly, why not hide it behind an abstraction? Then you can easilly mock it, use it for dependency injection etc:

http://www.iridescence.no/Posts/Linq-to-Sql-Programming-Against-an-Interface-and-the-Repository-Pattern.aspx

ADO.NET Data Services - IUpdatable on LINQ to SQL

Mike Taulty's Blog — Sat, 14 Jun 2008 14:04:50 GMT

I made an attempt at implementing IUpdatable on the current (i.e. VS 2008 Sp1 B1) bits of ADO.NET Data...

Showing some support for LINQ to SQL

Ian Cooper [MVP] — Wed, 02 Jul 2008 16:01:16 GMT

While I have finished my series on LINQ to SQL I wanted to talk about some of the reaction. In his summary

Showing some support for LINQ to SQL

Community Blogs — Wed, 02 Jul 2008 22:36:02 GMT

While I have finished my series on LINQ to SQL I wanted to talk about some of the reaction. In his summary

TDD, Architecture and Testing Code in Isolation :: Part 3

Loosely Coupled Human Code Factory - A.K.A. Mercenary Engineer — Thu, 10 Jul 2008 19:14:10 GMT

Navigate back to Part 2 of this series of entries. Ok, ok, ok, the other two parts where lean on the...

The Automated Testing Continuum - Part 2 (Unit Testing LinQ)

NixusG — Tue, 05 Aug 2008 22:11:03 GMT

The Automated Testing Continuum - Part 2 (Unit Testing LinQ)

Microsoft killing LINQ to SQL?

VistaDB .net database blog — Fri, 31 Oct 2008 17:21:49 GMT

Interesting blog post about it . And some related information on Stackoverflow posts . The basic gist appears to be comments made on the ado.net blog that state the Entity Framework is the only thing getting major developer time for Visual Studio 2010