Yep, it's been a while. Real work has gotten in the way.I was reading this post  about mocking the LINQ datacontext, and thought that it might prove useful to someone looking to try and mock the entity framework.Good luck - let me know how you get on with it!

Just an update on the mock entity framework provider - the idea behind it is so that you can develop unit tests against a disconnected dataset, which you can setup in memory as part of the tests, so that the data is in a known state  - rather than hitting a live database.  To that end I've been experimenting a bit with the sample entity framework provider.It seems that ObjectQuery cannot be created without specifying a context and a query string.  Shame, otherwise I could simply mock the call to the NorthwindModel.Customers { get; } call, and return my own ObjectQuery in place of the one the real provider would have returned.It seems that it's created in the entity framework code itself, where ther provider retrieves a datareader and converts it into an ObjectQuery of the class requested.This means that my "dataset framework provider"  will have to receive the eSql query command and return a data reader from the dataset that matches the eSql query.  This data reader will be picked up by the framework code, which will convert it to an ObjectQuery instance.I found this quite useful "template data reader" on the msdn pages, where there is example code on how to create a data reader.  I plan to look into that a bit more.I will also need to work out how the "dataset framework provider" will actually be given the dataset.Once I have a working sample project, I'll probably chuck it up on codeplex (if David Sceppa's happy for me to, as it will use a large part of the sample entity framework code - I'll have to check).[tags]entity framework, mock, provider[/tags]

Follows on from part 1As part of my investigations into the Entity Framework, I've setup a test project as a testbed.You can download it here: EF Research project. You'll need the Orcas beta 2 Pro (minimum), The Entity framework beta, and the Entity Framework ctp tools Project StructureI created a blank solution and added a class library called EfNorthwindLibrary. In this project, I've created a EntityFramework model called CustomersModel.edmx (Right click, add new item, Select ADO.NET Entity Data Model and follow the wizard). For the moment, the Customers model contains only a reference to the Customers table - I will be expanding on this as I go through my posts.Build EventsIf you look at the Build Events of the project (Right click, Properties, Build Events), you will see a Post-build event command line which looks something like "%windir%\ Microsoft.NET\ Framework\v3.5\EdmxDeploy.exe" "$(ProjectDir) " "$(TargetDir) " - this tells the project to take the .edmx files contained within the library and output them as csdl, msl and ssdl files into the project output folder. Apparently, this will ultimately become an msbuild task, so it doesn't need to be a post build event.App.ConfigIf you now look in the App.Config, you will see a Connection String entry that looks something like: This contains three sections: a metadata section, a provider section and a provider connection string section.The metadata section tells the framework where to find the csdl, msl and ssdl files, the provider section tells the framework which provider to use (this is where you can specify an alternative provider to the SqlClient - once they get written by third parties), and finally the provider connection string is a standard database connection string used by the provider. You can also specify all these settings in code if you prefer, but I'll come to that another time.CustomersModel.Designer.csYou'll see there is also a CustomersModel.Designer.cs file. If you have a look at it, you'll see it contains two classes - NorthwindCustomersEntities of type System.Data.Objects.ObjectContext, and Customers of type System.Data.Objects.DataClasses.EntityObject. Both these are generated from the .csdl file.The context class (NorthwindCustomersEntities) is how your application interacts with the model, and contains a collection of Customers in the form of a System.Data. Objects.ObjectQuery property. The constructor for the class takes in a connection string, an EntityConnection object, or nothing, in which case it uses the connection string found in app.config with the same name ("NorthwindCustomersEntities").The Customers class represents a single Customer record, and contains the various customer properties (CompanyName, ContactTitle etc...). It's a bit confusing, but the Customer table in the Northwind database is called Customers (plural, bad design), and the code generation just copies the names. We should be able to make it a singular that in the mapping at a later date.The above two classes also contain a couple of utility method,static Customers.CreateCustomers(customerId, companyName) - this returns a new customer instance.andNorthwindCustomersEntities.AddToCustomers(customers) - this adds a customer to the context.These are partial classes, so we can extend them later with our own business logic.Testing the generated classes and the mapping - Unit Test.The Visual Studio Test system has made it's way into the Pro version of Visual Studio 2008, so now I can run tests with the MS test framework, rather than nunit and testdriven.net (not that I don't like nunit and testdriven.net - I wonder how this decision will affect testdriven.net, as it's been a great alternative to paying full wack for the top end version of Visual studio).The Test project is called EF_Test (right click solution, Add New Project, Test Project). We need to add a reference to EfNorthwindLibrary, and references to System.Data and System.Data.Entity.We can create a new test such as:[TestMethod]public void TestConnectionStringWorks(){NorthwindCustomersModel.NorthwindCustomersEntities context = null;context = new NorthwindCustomersModel.NorthwindCustomersEntities();Assert.IsNotNull(context);}Run the test (On the menu, Text > Windows > Test View, and click Run Selection - don't try to run the project - you can start a class library!)Now, this will fail. We haven't passed the NorthwindCustomersEntities a constructor, so it's going to look in the App.config on the test project to find the connection (and it's not there). Lets add an app.config to the project, and copy in the connection from EfNorthwindLibrary app.config.Now it's still going to fail, because the connection in app.config references the .csdl, .msd and .ssdl files, which our test can't find. We're going to have to edit the LocalTestRun.testrunconfig file to tell it to copy the three mapping files output by the EfNorthwindLibrary to the test output folder. We do that by double clicking the solution file LocalTestRun.testrunconfig, goto the deployment option and click Add File - browser to EfNorthwindLibrary\bin\Debug and select the three files we need. Now these three files will get copied to the test output folder.Finally, make sure the metadata= in the app.config (for the test project) points to the files in the current folder, e.g. metadata=".\CustomerModel.csdl ...." etc because the original app.config has the .csdl etc files in a subfolder rather than the current folder.Now run the test - we should get a pass!Once we have the project at this point, we can start to explore more.Final note on unit testingFurther to this post^ on the msdn forums - when running unit tests, it should be possible to test business logic without hitting a real database (as this may require the database to be in a known state - a bad thing with unit tests). The usual method is to mock out the data access code. Anyway, that can't be done at the moment, so I'm working on a "Mock" entity data provider, so that your unit tests would be able to provide the data that the business logic expects to receive. Something like:

1. Create a dataset containing known data
2. Pass that dataset to the mockEntityProvider
3. Test the business logic of a class that querys the mockEntityProvider for the known data
4. Verify the results of the business logic.

Watch this space. In the next post, I'll be delving into the actual file structure and looking at adding an association to another table.

LINQ to SQL (server)I've been looking more into the new Microsoft Entity Framework since I found out that LINQ to SQL is a technology that can be used with Sql Server (and should perhaps be called LINQ to SQL Server).LINQ to SQL Server translates the LINQ query to sql server SQL, and contacts the database where required (if the object isn't already cached, for example).Fortunately, LINQ as a technology in itself can be used with collections in general, and is not tied to a database at all (ie, you can create an IList and then query it using the LINQ syntax), and can be used with the Entity Framework (more on this later - lets get on with an overview).Entity FrameworkThe traditional approach:Lots of coding time and effort tends to go into moving the data in the domain (eg, a Customer) back and forth between the application and the data store. The entity framework is designed to solve this problem.NOTE: The examples I'm using at present represent a 1 - 1 mapping between a data table and the application classes (as LINQ to SQL server), but the entity framework is able to map a data table to multiple classes, or multiple data tables to a single class, and map across multiple databases - these are major differences between LINQ to SQL server and the entity framework.Where the entity framework fits in:The entity framework, in essence, is a library that allows mapping between your classes and your database. This mapping is achieved with three files:1. The .csdl file describes to the framework what your classes look like:2. The .ssdl file - tells the framework what your database looks like.3. The .msl file - tells the framework how to transform between the .ccsl and the .ssdlThese three files are xml files. They need to be found by your application, so you need to provide a path to them (whether they are external files or embedded resources). There are a number of methods of creating these files

• Type them in manually
• Code generate them using the command line tool
• Code generate them using the designer tools - this generates a .edmx file that contains all three files. The files are separated out into the output folder when you build.

When code generating using the command line tool, you can tell it to generate classes from the .csdl file (this is done automatically when using the designer tools) - these are partial classes and you can extend them as you wish. LINQ to EntitiesNow we get to the fun bit - The entity framework has it's own query language (eSQL), very similar to SQL, that your code can use to retrieve classes from the database.As I understand it (someone correct me if I'm wrong) the provider that you specify in the configuration (eg. System.Data.SqlClient) translates the eSQL to the specific sql required by the database. This means that a third party can provide their own entity framework provider that will work with their database.Now, where as LINQ to SQL server translates the LINQ query to MS SQL, LINQ to Entities translates the LINQ query to eSQL - which is then translated into db specific sql by the provider. This means that you can use standard LINQ queries against the your entity framework model, with any database that has a provider (at present, only SQL).ConclusionThis is only a high level overview based on my understanding so far. In the next part, I'm planning on creating a mapping between a basic database and some code.Further resources:If you're interested in creating a managed provider, checkout David Sceppa's blog postMike Taulty has some useful posts on the Entity FrameworkTheServerSide has a good overview article (better than mine)

I'd just like to give a shout out to a great product I've been using recently called VistaDB (nothing to do with the windows OS!).It's a .net managed database - what this means is that you can host databases in medium trust environments (eg, a shared webhost, such as Fasthosts), and deployment is a snip (xcopy your app / website, the vistadb dll and the db file). It shares datatypes with Sql server, and is a breeze to use.It's not competition for sql server, it has different goals (mainly to be a managed database), but it makes it seriously easy to develop a commercial product that can be deployed simply by file copy.I'm currently investigating microsoft's Entity Framework (currently only compatible with sql server), although, unlike LINQ to SQL (which will only ever be compatible with ms sql), the Entity Framework has a provider model, allowing it to target different databases. When the guys at vistadb create their own provider (which is on their roadmap), the combination should be awesome.I'm planning on writing an article or two on Entity Framework soon.[tags]vistadb, entity framewor, linq, sql server[/tags]

There's a nice series of LINQ performance articles from Rico Mariani.  I haven't run my own speed tests yet, but he claims that they've increased the speed markedly from Beta 1 too Beta 2.Beta 1 was running select queries at about 1/8 the speed of a DataReader (LINQ uses datareaders under the covers), but they have made a 3.8x improvement under the covers with Beta 2.He discusses compiled queries where you can define the query, and execute it later with parameters (sounds a bit like a stored procedure!)  This means that LINQ doesn't need to generate the SQL each time the query is called, thus saving time on each execution.  By using compiled queries you can achieve a 6.6x improvement over beta 1, or a speed of around 93% that of a raw datareader.The series of articles is herePart 1, Part 2, Part 3, Part 4, Part 5.(I've posted this mainly as a bookmark for myself).[tags]LINQ, Orcas, .net 3.5, database[/tags]

I've recently started to experience a screen corruption issue in Visual Studio 2005 when running in on XP in VMware.   It manifests itself by not drawing the dataset designer tables when a dataset is opened - the screen instead displays the last image shown (e.g. a dialog box or the last screen of code).  If you click around, the individual tables will appear eventually as you click on them, but it's more or less guesswork.This example shows that the datatable is displaying over the last page shown, essentially, the background is not refreshing, and the datatables only appear when you manage to click on them.SolutionThe solution is to disable hardware acceleration  in windows.   R/Click desktop > Properties > Settings > Advanced > Troubleshoot), and change the Hardware acceleration to the third step.This fixes the display.As it has only started recently, and no software has been installed apart from windows updates, , I can only think that it was a windows update / driver update from windows update that changed things.    Anyway, it's working now, and hopefully this will be useful to someone.[tags]visual studio, vmware, xp, display corruption[/tags]

One of the most exciting things I've been working with recently has been LINQ to SQL, which is available in VS2008 (orcas) .net 3.5 beta. Summary LINQ to SQL is Microsoft's sql mapping framework, created by Anders Hejlsberg (the lead architect of C#, and if my memory serves me correctly, Borland Delphi, both great technologies). The idea of LINQ to SQL is that you can effectively query in memory and database mapped objects, with deferred loading available. You can provide a series of classes, and through either attributes or an xml mapping file, map these classes to your database. Some new syntax Before we start talking about the database side of things lets have a look at some syntax. Suppose you have a List where the list of orders is populated somehow, and you wanted a new list of orders where order.IsOpen == true. The .net 2 way of doing it would be:

List myOpenOrders = new List();
foreach (Order o in MyOrderList)
{
  if (o.IsOpen == true)
  {
    myOpenOrders.Add(o);
  }
}

or the more concise

List myOpenOrders = orders.Find(delegate (Order o)
           { return o.IsActive == true});

Anyway, LINQ provides an SQL Query like method to query a list.

var myOpenOrders = from order in orders
        where order.IsOpen == true
        select order

var is a new typesafe inferred type, checked at compile time. So in this instance, myOpenOrders represents an IEnumerable, but you could just as easily declare

var myInt  =5;

But why not just declare an int, or an IEnumerable I hear you ask! - because using another new feature of .net 3.5, you can also create types on the fly:

var MyNewType  =  new {Name = "Chris", Age="32" };
MyNewType.Name = "Chris Buckett";

This is useful if we consider the myOpenOrders query again:

var myOpenOrders = from order in orders
        where order.IsOpen == true
        select new {
            OrderNum = order.OrderNumber,
            OrderDate = order.OrderDate
        }

This creates an IEnumerable of our new type, which you could access like:

myOpenOrders[0].OrderNum

Or more likely, databind the result to some output. Finally, we can also use the new "Lambda" syntax to return just one item.

Order myOrder = orders.Single(o => o.OrderNumber == 123);

Single is an Extension Method - another new feature whereby you can add functionality to a class without inheriting from it. I'll probably blog about that at some other point. Suffice to say that good old intellisense gives you a nice list of provided extension methods when you type order. The Lambda syntax (o=>o.OrderNumber ...) in the context of single is more or less a shorthand for the following:

foreach (Order o in orders)
{
    if (o.OrderNumber == 123) { return o; }
}

Except that the Single method will generate an exception if nothing is found. If you'd like to return null, rather than generate an exception, then use SingleOrDefault(). Back to LINQ to SQL So, we can see we can query a list of objects - this is where linq to SQL comes in. By defining a DataContext (either using the drag and drop visual designer, or creating your classes and mapping them to the database), and then using that datacontext to retrieve your list of objects, you can easily query the database to retrieve the objects you require. The datacontext also has useful caching, so only the objects that aren't already in the cache are pulled from the database. For example:

MyDataContext dc = new MyDataContext(myConnectionString);
var myOpenOrders = from order in dc.Orders
        order.IsOpen == true
        select order;

And to select a single record:

Order order = dc.Orders.Single(order => order.OrderNumber = 123)

And finally, we can modify that order and save the changes back to the database with the following:

order.IsOpen = false;
dc.SubmitChanges();

One other useful thing that LINQ to SQL provides is the ability to access child objects, for example:

var myExpensiveOrderItems = from orderItem in order.OrderItems
             orderItem.Value > 500
             select orderItem;

Or

OrderItem orderItem = order.OrderItem.Single(oi=>oi.ItemCode == "ABC123");

And you can reference the order from that order item using

orderItem.Order

And so on. There's a load more, and I would recommend either Scott Gu's descriptions, or Mike Taulty's videos to give you some better insight. Getting back to the point. So, the thing that excites me today is the promised functionality in the upcoming Beta2, specifically Entity Object Validation. By creating a partial class for the entity type (say Order, which has been auto-created by the drag and drop designer, for example), you can declare the following (and yes, this is very similar to Scott Gu's example, as it is what I've just read:

public partial class Order 
{
  partial void OnValidate() 
  {
    if (Order.OrderDate < DateTime.Today) 
    {
      throw new Exception("Order date is before today");
    }
  }
}

When you call SubmitChanges , OnValidate is called. If the exception is thrown, everything is rolled back (because all LINQ queries are executed within their own transactions). Note another new piece of syntax: partial methods. This allows you to develop a class with a method stub, e.g.

public partial class MyClass 
{
  partial void DoSomething(string someValue);

  public string MyPrivateProperty
  {
    get
      {
        return _something;
      }
    set
      {
        _something = value;
        DoSomething(value);
      }
    }
  }
}

and then in another file, you can use:

public partial class MyClass 
{
    partial void DoSomething(string someValue)
    {
      //Some code here
    }
}

The main benefit I can see of this is that you can easily use generated code, such as that from the LINQ visual designer, and then extend that code in separate files buy using partial classes and partial methods. That way, if you regenerate the generated code, all you hard work doesn't get wiped out by an over-eager code generator. Further reading: Linq tutorials from Scott Gu More talk about partial methods There is also quite a good piece on phoen blog about whether technologies such as LINQ will affect database best practices - essentially making that point that with LINQ technologies, developers steered towards using the database simply as a "bit bucket" or object repository. One final useful link for those TDD inclined is Ian Coopers post with a useful example of testing your LINQ classes without accessing the database. [tags]LINQ, Orcas, vs2008, .net 3.5, Database[/tags]

I've just revisited an old project to add a TableAdapter to a Dataset, and received this error when trying to load the VS2005 designer.

Failed to load dataset because of the following error:

Unable to find connection 'MyDatabaseConnectionString (Settings)1' for object 'Settings'. The connection string could not be found in application settings, or the data provider associated with the connection string could be loaded.

The project builds and runs without error, but there was obviously something wrong.  Looking through the settings and app.config reveals no errors. It turns out that the .XSD dataset file (which is represented visually) has a duplicate connection string.  You need to edit it in notepad and remove the extra line, from:

.... etc...

to:

.... etc...

Easy. It's one of those obvious ones with a cryptic error message. [tags]Visual Studio, Dataset, Error[/tags]