A while ago, I talked about how to write basic events for changed properties, and about the INotifyPropertyChanged interface. There is a third way to manage events, which is especially useful when your class has many events, but you expect a very low number of them to be actually handled.

As discussed before, every EventHandler stored in your object takes up space, which is a bit of a waste if most of those will be null. But events allow you to implement the add and remove methods yourself, so you can choose where to store the EventHandler delegate.

One way to do that is through the System.ComponentModel.EventHandlerList class. System.ComponentModel.Component exposes an Events property of this type, which is used by all classes inheriting from Component, including all Windows Forms controls.

See my U2U blog for a complete example, featuring a CueBannerTextBox (like the Internet Explorer 7 search box) with a CueBanner property and a CueBannerChanged event.

The DataContext.Log property is a great help to learn writing LINQ To SQL queries. All you need to do is assign a TextWriter to it, and you get to see al the SQL statements generated by the data context. But where do you send them to? Console.Out is an option, but you probably don’t want that in a release build. Furthermore, it doesn’t quite work for Windows services or ASP.NET applications. That’s why I wrote DebuggerWriter, an implementation of TextWriter that writes to the debugger log.

Find the code at my U2U Blog.

Just in case you haven’t figured out yet who they are competing against, Michael Swanson released a free Macromedia Flash to WPF/E converter…

Also this week, Microsoft released Expression Blend Beta 1 (formerly known as Expression Interactive Designer, a graphical WPF XAML editor) and Expression Design December 2006 CTP (formerly known as Expression Graphic Designer).

Expression Blend looks good, though the first thing I did was change the default dark theme to the light theme, and decrease the workspace zoom to 90%. I need a bigger screen…

I’d say it’s about time you uninstall that cracked Photoshop!

While the LINQ to XML programmer operates on generic XML trees, the LINQ to XSD programmer operates on typed XML trees — instances of .NET types that model the XML types of a specific XML schema (XSD). [...] LINQ to XSD is integrated into Visual Studio; so you just tag an XML schema as [a] ‘LINQ to XSD schema’, build your project, and the automatically derived object model is then part of your solution — just as if XML schemas were .NET types.

I only had a quick look, but I have to say it looks very promissing! Send them your feedback, but hurry, I want this to be included in Visual Studio Orcas.

A simple start

Let’s take a look at the following code:

Northwind db = new Northwind(@"c:\\northwind\\northwnd.mdf");

var q = from c in db.Customers
        where c.City == "London"
        select c;

foreach (var cust in q)
  Console.WriteLine("id = {0}, City = {1}", cust.CustomerID, cust.City);

It should be clear that the first line belongs in the DAL. The DataContext encapsulates a database connection, and knows about the physical location of the database. That is not something that higher layers should know about.

Let’s say the actual query definition belongs in the DAL too, but clearly, the foreach loop sits in some higher layer. That means the two first statements need to be encapsulated in some function in the DAL, for example as follows (sticking with the “Entity Access Layer” terminology introduced before):

public class CustomersEal
{
  private Northwind db = new Northwind(@"c:\\northwind\\northwnd.mdf");

  public IQueryable<Customer> GetCustomersByCity(string city)
  {
    return from c in db.Customers
           where c.City == city
           select c;
  }
}

The business layer then contains the following code:

CustomersEal customersEal = new CustomersEal();

foreach (var cust in customersEal.GetCustomersByCity("London"))
  Console.WriteLine("id = {0}, City = {1}", cust.CustomerID, cust.City);

Looks good, doesn’t it? All the business layer knows about the database, is that it can return Customer objects.

Problems

But wait, what if I write the following in my business layer:

CustomersEal customersEal = new CustomersEal();

var q = from c in customersEal.GetCustomersByCity("London")
        orderby c.ContactNamer
        select new { c.CustomerID, c.City }; 

foreach (var cust in q)
  Console.WriteLine("id = {0}, City = {1}", cust.CustomerID, cust.City);

This code highlights a few interesting facts.

First of all, it wasn’t the DAL that executed the query, at least not in the traditional sense of the word. The DAL (CustomersEal to be precise) merely supplied the definition for the query. The query got executed when the foreach statement started looping over the result! In a traditional DAL, a call to a method like GetCustomersByCity would have executed the query, but not with Linq, at least not if we implement our code like this.

Secondly, the business layer can refine the query definition. This definitely has some advantages, but I realize some might argue that this is really bad. Note though, that the business layer cannot redefine the query, or execute just any query it wants. Or can it? You need the DataContext to start the process, and only the DAL has access to that, right? In fact, the Entity Layer generated by SQLMetal is referenced by the business layer too, it needs it to get to the definitions of the entities!

Thirdly, it is absolutely not clear where a developer should draw the line between what’s business logic, and what belongs in the DAL. I could have moved the orderby into the DAL (especially if I always want customers to be ordered by their ContactName). But likewise, I could have moved the where clause to the business layer! How do I decide what to do?

I hate it when developers have to make choices like that during routine development. Choosing takes time, and that’s not likely to improve productivity. But much worse is the fact that different developers will make different choices. Even a single developer may make different choices from one day to the next. That leads to inconsistencies in the code. Developers will spend more time trying to understand the code they’re reading, because it doesn’t always follow the same pattern. That’s bad for productivity. In the worst case scenario, developers start rewriting each other’s code, just so it matches their choice of the day. That kills productivity. (Wasn’t Linq all about improving productivity?)

The solution?

We need a clear and simple criterion to decide which code goes where.

Note that the absolute minimum for a DAL is the following:

public class CustomersEal
{
  private Northwind db = new Northwind(@"c:\\northwind\\northwnd.mdf");

  public IQueryable<Customer> GetCustomers()
  {
    return db.Customers;
  }
}

It’s a bit silly of course, if that’s all this layer does, we might just as well skip it (the connection string should be externalized in a configuration file anyway, and a default constructor that reads the connection string from the config file should be added to the Northwind DataContext in a partial class). Silly or not, it is a “lower bound” to an EAL as we have defined it here. I believe there’s an “upper bound” too: I think the DAL shouldn’t do projections (well, it definitely should not expose anonymous types). But that still leaves us with a very broad range. How to make a choice?

I’m inclined to say that the only way to make a clear and simple choice once and for all, it to go with the minimalist approach. And indeed, that means we don’t need/write/use an Entity Access Layer. The business logic directly accesses the one assembly generated by SQLMetal.

How’s that for a DAL?

Let’s start by trying to create a (working) definition of a DAL. Wikipedia is usually a good place to start, but you’ll find that the Wikipedia article on DAL’s doesn’t exactly contain all the answers. So let’ give it a try ourselves.

A DAL is a layer. That means its part of a layered architecture. Other layers use the DAL to do data access. Indeed, the DAL is the layer accessing the data (and in the context of Linq to SQL, that’s relational data), and no other layers access the data directly.

That’s a good start, but what is layer? Is that a special kind of component? Not in my mind it isn’t. To me, a layer can contain multiple components, and that applies to a DAL as well. Let’s say I have a simple banking system. It contains functionality on clients, their accounts, and the operations (such as money transfers) they do on those accounts. That might result in a vertical partitioning of the application in three modules, “Clients”, “Accounts” and “Operations”. Each of those would be layered, and you’d find components at the intersections of the vertical modules and the horizontal layers. So you’d have ”Clients DAL”, “Accounts DAL” and “Operations DAL” components. Obviously, these components are related, they have dependencies between them. The Operations DAL depends upon the Accounts DAL (and possibly the Clients DAL as well), and the accounts DAL depends on the Clients DAL.

In .NET, components like these correspond to assemblies. So our DAL would consist of several assemblies, with (non-circular) references (dependencies) to each other. Which part of the functionality do we put where?

The Clients DAL doesn’t know about accounts, that’s the responsibility of the Accounts DAL. That one knows about accounts, and about clients as well. After all, accounts are owned by clients. So that means the function to retrieve the list of accounts belonging to a given client sits in the Accounts DAL, not in the Clients DAL. Since this function has a client as a parameter (or at least a client id), the Accounts DAL may indeed need a reference to the Clients DAL. Each object returned by this function has a reference to the client owning the account, or at least the id of that client.

But wait, what’s the impact of Linq to SQL on what I said so far? If I have a database with Clients and Accounts tables (amongst many others) with a foreign key between them, the typical Client and Account entity classes will have a relationship between them as well. The Account class will have a delay-loaded Client property, and the Client class will have an Accounts property. That’s a mutual dependency, so these two classes need to sit in the same assembly. But where does that lead us to? Typically, all tables in a database are somehow related to each other, i.e. there are no disconnected islands of tables with relations between them, but no relations to other islands in the database. But that leads us to just one DAL per database! Is that what we want?

Well, SQLMetal, the Linq to SQL tool that generates an entity model based on a database schema, definitely pushes us in that direction. Typically, it generates one source code file containing one DataContext and all the entities in your data model. But that’s just the entities though, that code doesn’t do any data access! To actually access the data, you need to write queries! And those queries are the responsibility of our DAL components.

In our example above, we had three DAL components, and all three of them would access the same DataContext. That implies that the DataContext should exist in an assembly of its own, an assembly underlying all DAL assemblies. But that’s an additional layer, isn’t it?

Well maybe it is. Maybe we need to split our traditional Data Access Layer into two distinct sublayers. For lack of better terms, I’ll call them the “Entity Layer” and the “Entity Access Layer”.

The Entity Layer has just one assembly in it, so we might just as well refer to that assembly as the Entity Layer as well. The entire assembly is compiled from just one code file (and some housekeeping stuff perhaps, like an AssemblyInfo.cs file), generated by SQLMetal.

The Entity Access Layer (EAL) has several assemblies (three in our example), all using the Entity Layer. The EAL assemblies contain the actual queries.

Next time, we’ll look at the interface between the EAL assemblies and the business layer: what parameters are used, what results are returned? Do we expose the Entity Layer types? Do we expose query expressions or query results only?

That’s enough food for thought right now, and comments are more than welcome.