Ian Cooper [MVP]

Architecting LINQ To SQL Applications, part 8

2008-04-06T18:58:00Z

Previously: Architecting LINQ To SQL Applications, part 7

Tiers
A layer, such as we discussed Part 2, in is not a tier. A layer is a logical unit of division; a tier is a physical unit of division. The two need not be the same. Software may be layered within a single process running on one machine or across a number of processes running on different machines. Layering is about separation of concerns. Physical distribution is about sharing and scalability. So for example an RDBMS tends lives on a server, because we want to share data among many users in a scalable fashion. Some rules of thumb are:

Presentation Layer: This is the most obvious. For a rich client we need run our presentation layer on the client. Remember that we might consider a browser application to be a rich-client if it uses JavaScript and DHTML to provide its UI i.e. Ajax. For a thin client application the presentation runs on the server.
Application and Domain Layer: This may run in the same place as the presentation layer, and this is the most responsive option. An application server runs the application and domain logic on a server. It allows sharing of the functionality exposed by the domain across multiple clients or to other applications. Running an application server can also lower cost of upgrades in a rich-client environment, because you update the domain logic in a smaller number of places.
Infrastructure Services: Because the application and domain layer depend on the infrastructure services they tend to run with the application and domain layer or on their own server.

(As an aside, layers do not constrain packaging decisions either (i.e. how to divide your application into assemblies) and packaging decisions are again seperate from tiers. I do not intend to cover packaging decisions here. One of the best discussions is in Robert Martin's Agile Principles, Patterns, and Practices in C#. The NDepend tool is invaluable in helping you make sensible packaging decisions.

The Laws of Distribution

The first law of distributing your application into tiers is don’t.

Distribution is a complexity multiplier. Increased complexity equals increased cost. Software is an economic proposition to the buyer: what benefit they receive offsets the cost of purchase and ownership. The benefits of distribution come from sharing, scalability, and quality of service. Always make tier decisions with those criteria in mind so those are the criteria which steer us in that path. David Hayden has talked about this issue on CodeBetter before.

Scalability

Distribution will make your application more complicated and crossing process boundaries will make your application slower (calls across process or machine boundaries are orders of magnitude slower). So why would we scale our application? Many application servers seem to do little beyond passing a requests to the Db to and from the UI, doing little or no processing in-between. What are people using a server for here? Connection Pooling is the major driver. If our data access happens from within the same process, then we can share connections from a pool reducing the cost of creating and destroying connections.

However, for ASP.NET applications there is little to be gained here. Indeed, a lot of people separate their domain layer into an application server in this context without needing to. We gain the benefits of connection pooling obtained from running in a single process, by virtue of being hosted within ASP.NET. There is no need to introduce a seperate application server for connection pooling here. For smart clients we can gain benefits from pooling by doing data access from a server tier, because otherwise every client will have its own connection to the Db. So at a certain point a Windows Forms application may gain a performance benefit from using an application server, but its worth bearing in mind the need to trade this benefit against the performance costs of distribution to begin with.

The connection pooling example extends to anything where we have expensive creation. We may find it is more efficient to create once on the server and then allow mutliple clients to share that resource. Indeed if materialization of our objects from the Db were to be an issue then caching the objects so created and returning the cached copy from our server would relieve pressure on the Db, by allowing clients to retrieve the copy instead of re-issuing the request. However, we would need to make decisions about the importance of the liveness of our data and how our cache would be refreshed if it became invalid.

In addition, where we are performing intensive activity on the server we may want to improve the performance of our application by splitting the work up and then scaling out or up. In this case we put the work into a server and share the work out among a pool of servers. Where the application server does a lot of work, for example complex calculations, then adding an application server allows the number of nodes where that calculation can be performed.

Shared Services
Sharing creates pressure for a middle tier, especially if we want a service oriented architecture where there is one authority within our enteprise for certain operations. For example in an insurance company a number of applications might require access to our rating information. By hosting this information in a service we make it possible for any application within the enterpise to obtain that information. If it was locked into a smart client (for example an Excel spreadsheet) it would be difficult for other applications to share that information. A rich client cannot share the knowledge of the domain it captures, or the results of calculations, and in this circumstance you are always forced into moving this knowledge onto the server.

Quality of Service
We may want to provide our application with multiple nodes to improve its fault tolerance; if we lose one node other nodes can continue to carry out work. We might want to run a service our application uses in a different security context to that which the application uses. We might want our application to use reliable messaging for an operation. All of these issues can be loosely grouped as quality of service concerns and we may want to distribute our application to avail ourself of these services.

The Last Responsible Moment
Beware premature decisions here. Just because you may need to expose this knowledge as some point, does not mean that you need to do so from the beginning. A well-layered application would be amenable to refactoring to a mult-tiered one, when you need it to be. I would try to defer the cost of distribution, until you know you need it. Bear in mind for example that a web application just uses the HTTP protocol to exchange HTML with a browser. To add a second ‘presentation’ layer that exposes XML over HTTP instead, to a calling application instead of a browser, should be a straightforward change to your existing architecture. Indeed, identifying the services the application provides may be easier if we look toward what ‘services’ we provide via HTML.

Why is there pain going multi-tier with LINQ To SQL?
Assuming that you have worked through options and decided you need an N-Tier application, the question becomes: what issues will you hit when you try to use LINQ To SQL in this context.

Serialization
It is not straightforward to serialize an entity between two tiers.

The first issue is that XMlSerialization fails with circular-references so XMLSerialization will tend not to work where you are managing a parent-child relationship with an EntitySet-EntityRef pair. The designer does have a workaround for this in WCF, so that you don't serialize both parts. There is a good summary of the issues here and here.

Entity-lifetime management

The second issue is DataContext. Remember how we talked about the DataContext as a unit of work in which we should manage all of our interaction with entities. Passing an entity to another tier removes it from its extant unit of work. Assuming that you intend to work with the entity on another tier and then pass it back to update the Db with any changes, you will need to bear in mind that you are converting a peristent entity to a transient one and back again. There are two ways of dealing with this round trip. The first is to attach the entity to the DataContext when you deserialize it, to let the DataContext know that it is really a persistent object. As previously discussed, to effect this you think about how you will manage the 'prior' state by, for example, tracking the old state of the entity yourself. The second is to think of your deserialized object as set of deltas to the current Db representation of the entity and load the entity from the Db within the current DataContext and change it to reflect the object you have deserialized.

This suprises some people because they are used to working with DataSets, which formed a unit of work, and were serialized with both the old and current state of the rows they contained, allowing the updates to be played through a DataAdapter when they were passed back to the middle tier. LINQ To SQL does not support this model 'out-of-the-box'. This tends to shock people who expect that the features of DataSets should somehow extend to LINQ To SQL.

We'll cover solutions to these issues next time, but as a teaser I would point out that the 'Replay' model above is common in web applications. There we create a DataContext and load any entities required in response to a request for a page; compose an HTML response to that request from those entities and then dispose of out DataContext. If the user is editing they send a message from their browser in return with changes that indicate the modifications we want to apply to the entity. In response to that postback we load the entity from the Db again, using a fresh DataContext, and apply the edits that the user has made to it.

Note how we are exchanging messages with the browser, in the form of HTML, instead of serializing objects. This basic pattern of message exchange forms the heart of how we should architect out n-tier applications when using LINQ To SQL.

Architecting LINQ To SQL Applications, part 7

2008-03-09T18:55:00Z

Previously: Architecting LINQ To SQL Applications, part 6

The topic of managing entity lifetimes is an important one as many of the issues that people have when using an ORM for the first time relate to a lack of understanding of how an ORM manages objects loaded from the Db, or that are to be inserted into the Db. In addition over the next few installments we will begin to talk about some of the issues related to multi-tier scenarios. It is important to understand how lifetime is managed because many of the issues people have come from working against the ORM rather than with it in these circumstances.

What are Entity and Value types

An Entity is a type which has an identity that remains unique and consistent throughout its lifetime. It is a unique in the sense in that it must always be possible to distinguish one entity from another. It is consistent in that even if the attributes change, the entity will still retain its identity. Consider a Customer type. As an entity we must be able to distinguish one customer from another. We need to somehow define Customer identity through a member. We avoid using natural members like Name because they are not individually unique and may change over time. Instead we base the identity of our entity on a surrogate member that gives us identity instead. In this case we might define an Id member for our Customer that assigns them a unique value within our organization.

Within the Db a primary key field distinguishes an entity, which is represented by a row on a table. LINQ To SQL piggybacks on this to provide support for an Entity, via a type mapped via a Table attribute or mapping, that corresponds to a table that has a primary key. So we map our Customer class to a Customer table and our Id member to an Id primary key field on that table. Again natural keys are allowed, but should be avoided in favour of surrogates to ensure that our entity remains unique and identifiable throughout its lifetime.

The counterpart to an Entity type is a Value type. A Value type takes its identity from the value of its attributes. Two entities that have the same attributes, compare the same. For example two postcodes that have the value "ABC 123" compare the same so we consider them to have the same identity. A value type might have just the one attribute, as with our postcode example, but also might have multiple attributes. An example of a value type with multiple attributes would be a Money type that has both an Amount and a Currency. We want to compare two instances of Money for GBP 123.74 as equal.

Within the DB a Value is represented as one or more columns within the row of an entity. LINQ To SQL only supports primitives as Values i.e. string, int, etc. and has no support for mapping user-defined value types. Thus there is no direct support in LINQ To SQL for types like Money. Hopefully this is a limitation that will be addressed in future versions.

Entity Lifetime

A data context is a unit of work. It tracks changes and submits updates to the Db when flushed. Because of this you should only keep it around long enough to do the work ...but no longer. When working with a DataContext we need to distinguish between, to borrow Hibernate terminology, transient and persistent entities.

Persistent objects have been loaded by LINQ To SQL and we have a reference to them in the DataContext’s identity map. The DataContext tracks changes for the persistent entity against the time that they were loaded. Future requests for that object, will return the object in the cache. Changes to that entity can be submitted to the Db. Lazy Loading of associations, uses the same DataContext we loaded the entity with originally.

An entity that is not in the identity map of the DataContext is a transient entity. It has a lifetime equivalent to the running application. To ensure that the entity persists we need to add it the matching table on the DataContext using InsertOnSubmit and flush it using SubmitChanges on the DataContext, causing the entity to become persistent.

MyContext context = new MyContext();

//persistent object
MyObject myOldObject = context.MyObjects.Where(m => m.Name == "Old").Single();
//changes are tracked
myOldObject.Name = "Changed Name";

//new entity; transient
MyObject myNewobject = new MyObject();
//no need to track; no Db row to update yet
myNew.Name = "New Name";

//make new object persistent and flush changes to old objects
context.SubmitChanges();

This is not always intuitive:

MyContext anotherContext= new MyContext();

//new entity; transient
MyObject myNewobject = new MyObject();
myNew.Name = "New Name";

//new entity is still transient until we actually submit
anotherContext.MyObjects.InsertOnSubmit(myNewobject);

//not persistent, won't be found
var results = anotherContext.MyObjects.Where(m => m.Name == "Old");

It is important to note that although an identity map is sometimes called a first-level cache its purpose is not to optimize retrieval of entities from the Db. Because the ORM, such as LINQ To SQL does not know the results of a query it cannot determine whether two calls to a query (even if it is the same query as other users may have updated the Db) will return the same result set. For this reason it must always bring the result set back, and then check for the existence of those entities within the identity map. If the map contains the item, we must return that instance instead because you might have made changes to the entity and we want to preserve them througout the unit of work. For this reason the cache is not about optimisation but about ensuring you do not lose changes during your unit of work. It is possible that queries that request an entity by primary key could be retrieved from the map directly, where they are already loaded, but you should not rely on this optimization.

Because we hold the object within the identity map for the lifetime of the unit of work there is a danger of concurrency errors, where another user updates the Db while we have the object. For this reason the identity map stores the original version of our object as well as the current one. This allows LINQ To SQL to compare the original against the state of the Db when it issues an update or delete query and raise an optimistic concurrency violation error if it has changed. Of course if you use a timestamp and set Update.Never on your mapping to inform LINQ To SQL that it should not check that field when looking for concurrency errors you can optimize this feature as well. However the optimal SQL issues by LINQ To SQL during an update still depends on knowing what has changed.

LINQ To SQL supports a Refresh method on its DataContext to force a reload of an entity or attributes of an entity. The purpose here is to allow you to resolve optimistic concurrency errors or to reload an object during a unit of work if you are aware that the Db has been changed by a mechanism outside of the purview of LINQ To SQL. The Refresh just goes back to the Db to find the latest version of your object. Note that refresh targets specific objects in the map or a set of objects.

You can disable use of the identity map by setting ObjectTrackingEnabled to false. The purpose here is to optimize when you are loading read-only collections i.e. you never want to submit changes on these objects back to the Db. Remember though that another DataContext will consider these to be transient objects, so avoid assigning references loaded this way into entities loaded via DataContexts which are tracking.

Attaching Entities

Sometimes we have an entity that is in the backing store but not in the identity cache of our DataContext. To make our DataContext aware that this is a persistent and not transient entity we need to Attach it to our DataContext. This puts it in our cache. However, our context cannot know if the entity is the same as the representation on the backing store, so it must assume so and change tracking will consider your object to be in the ‘original’ state. If your object has changed and you try to save those errors, you will get optimistic concurrency errors. This is because when we compare your ‘original’ to the Db, they do not match, which fools LINQ To SQL into thinking another user has changed it since we loaded it.

One option to avoid you must tell the DataContext what the original state in the Db was or set your columns as UpdateCheck.Never. If you have a Timestamp column, you can rely on that to do the right thing for you. Sometimes people suggest an Update.Never on every column strategy, where you cannot use a timestamp, but the danger is that we can overwrite genuine changes by another user.

Otherwise we need to either provide the original, by maintaining the original state for any objects we may choose to detach, or adopt a load and replay strategy for detached objects where we load the current representation from the Db and then write our changes over it.

Think carefully before heading down the detached objects route as it multiplies the complexity of what you are doing. This issue most often raises its head in multi-tier scenarios. We will talk about how to handle those in a future blog post, but for now recognize that the unit of work implies that the framework will not help you track changes outside of that context.

Managing DataContexts

Do not try to work with two different contexts at the same time. This is because what are persistent entities for one look like transient entities to the other because it does not have them in its identity map, as it did not load them.

Do not try to access an object graph loaded via LINQ To SQL outside of its DataContext if it has lazy loaded properties. This is because LINQ To SQL will access the original DataContext to load the entities. Trying to lazy load within another context falls foul of our earlier rule not to mix our contexts.

Finally, assume that a DataContext is not thread safe i.e. work with a DataContext only on one thread and do not try to pass entities retrieved via a DataContext on one thread, to another thread.

When working with a web application consider creating a DataContext per http request, using it to retrieve and then submit any changes required by the session. For a client-side application consider using a DataContext for each application transaction.

While a DataContext is disposable, only dispose of it when you finish your request or application/transaction and are finished with the persistent entities that it loaded.

Exercise caution around caching entities that were loaded via a DataContext. This is because when you access those elements they may still refer to the DataContext if they contain a lazy loaded association. If you want to use LINQ To SQL to load cached data, make sure you load objects that are not coupled to the DataContext, by not using EntitySet<> and EntityRef<> for associations, and disabling deferred loading on the context that you use to load them. This can be appropriate for reference data, in which case, you can also disable change tracking.

Is LINQ To SQL deficient here?

I read a fair number of opinions that are suprised by the behavior of LINQ To SQL. However, having used ORMs for a number of years, I find LINQ To SQL conforms to my expectations as to how an ORM should behave. Indeed a reading of something as old now as Martin Fowler's Patterns of Enteprise Application Architecture and you will find exactly this pattern of behavior for an ORM discussed. Indeed WORM (Wilson O/R Mapper now open source BTW) and NHibernate both behave in a similar fashion. So some of this seems to be based on expectations that don't come from experience of using ORM tools. On a recent .NET Rocks there was an opinion expressed that LINQ To SQL was somehow only fit to be a RAD tool because of multi-tier issues. I can't agree with this opinion at all. LINQ To SQL has a similar feature set to WORM, on which I have built distributed enterprise applications. Its limitations relate to the diversity of mappings that it supports (table per concrete class in an inheritance hierachy or value types for example) and its lack of support for multiple Db vendors, not some percieved issues around the unit of work and identity map patterns which it implements.

Architecting LINQ To SQL Applications, part 6

2008-03-09T18:01:00Z

Previous: Architecting LINQ To SQL Applications, part 5

Mapping with XML files instead of Attributes

Greg Young pointed out in the comments to the last post that using attributes can clutter your domain objects. Although it is simpler to show attributes first, so that you can relate rolling your own mappings to the designer generated code, I did not want to leave the story incomplete without showing you how to move those mappings into a file in order to keep your domain objects clean.

The correspondence between the mapping file and the attributes is straightforward. Instead of attributes we just have XML elements and instead of properties on those attributes, we have attributes on our XML elements.

First of all we need to create a text file to hold our mappings. We call it Keysafe.map. Next we need to indicate the xml encoding:

<?xml version="1.0" encoding="utf-8"?>

Now we need to open up a Database element, which will form the root of our mapping.

<Database Name="northwind" xmlns="http://schemas.microsoft.com/linqtosql/mapping/2007">
</Database>

Within the Database element we need to add a Table element for each entity we wish to map (equivalent to our [Table] attribute).

<?xml version="1.0" encoding="utf-8"?>
<Database Name="northwind" xmlns="http://schemas.microsoft.com/linqtosql/mapping/2007">
<Table Name="dbo.Category">
</Table>
</Database>

Because we are not using an attribute we have to tell LINQ To SQL what type our table maps to explicitly:

Then we need to map out our Columns. Again because we are not associating our attribute with a member, we have to explicitly indicate the member.

<?xml version="1.0" encoding="utf-8"?>
<Database Name="northwind" xmlns="http://schemas.microsoft.com/linqtosql/mapping/2007">
<Table Name="dbo.Category">
  <Type Name="KeySafeDomain.Category">
   <Column Name="Id" Member="Id" DbType="Int NOT NULL IDENTITY" IsPrimaryKey="true" IsDbGenerated="true" UpdateCheck="Never" AutoSync="OnInsert" />
   <Column Name="Name" Member="Name" DbType="NVarChar(50) NOT NULL" CanBeNull="false" UpdateCheck="Never" />
   <Column Name="ParentId" Member="ParentId" DbType="Int" UpdateCheck="Never" />
   <Column Name="Version" Member="Version" DbType="rowversion NOT NULL" CanBeNull="false" IsDbGenerated="true" IsVersion="true" AutoSync="Always" />
  </Type>
</Table>
</Database>

As before the DbType information is there to help us generate the Db from our domain model.

We also need to map out the associations between our classes. Again the conversion between the attribute based model and our XML model is straightforward.

At this point it is just grunt work to translate our previous attribute based mappings into an XML mapping file.

In the end our mapping looks like this:

<?xml version="1.0" encoding="utf-8"?>
<Database Name="northwind" xmlns="http://schemas.microsoft.com/linqtosql/mapping/2007">
<Table Name="dbo.Category">
<Type Name="KeySafeDomain.Category">
<Column Name="Id" Member="Id" DbType="Int NOT NULL IDENTITY" IsPrimaryKey="true" IsDbGenerated="true" UpdateCheck="Never" AutoSync="OnInsert" />
<Column Name="Name" Member="Name" DbType="NVarChar(50) NOT NULL" CanBeNull="false" UpdateCheck="Never" />
<Column Name="ParentId" Member="ParentId" DbType="Int" UpdateCheck="Never" />
<Column Name="Version" Member="Version" DbType="rowversion NOT NULL" CanBeNull="false" IsDbGenerated="true" IsVersion="true" AutoSync="Always" />
<Association Member="Children" Storage="children" ThisKey="ParentId" OtherKey="Id"/>
<Association Member="Parent" Storage="parent" ThisKey="ParentId"/>
<Association Member="Systems" Storage="systems" OtherKey="CategoryId"/>
</Type>
</Table>
<Table Name="dbo.ITSystem">
<Type Name="KeySafeDomain.ITSystem">
<Column Name="CategoryId" Member="CategoryId" DbType="Int NOT NULL" UpdateCheck="Never" />
<Column Name="Comments" Member="Comments" DbType="NVarChar(4000)" UpdateCheck="Never" />
<Column Name="Name" Member="Name" DbType="NVarChar(50) NOT NULL" CanBeNull="false" UpdateCheck="Never" />
<Column Name="Id" Member="Id" DbType="Int NOT NULL IDENTITY" IsPrimaryKey="true" IsDbGenerated="true" UpdateCheck="Never" AutoSync="OnInsert" />
<Column Name="Version" Member="Version" DbType="rowversion NOT NULL" CanBeNull="false" IsDbGenerated="true" IsVersion="true" AutoSync="Always" />
<Association Member="Keys" Storage="keys" OtherKey="SystemId"/>
<Association Member="Category" Storage="category" OtherKey="Id" ThisKey="CategoryId"/>
</Type>
</Table>
<Table Name="dbo.Key">
<Type Name="KeySafeDomain.Key">
<Column Name="Id" Member="Id" DbType="Int NOT NULL IDENTITY" IsPrimaryKey="true" IsDbGenerated="true" UpdateCheck="Never" AutoSync="OnInsert" />
<Column Name="Password" Member="Password" DbType="NVarChar(50) NOT NULL" CanBeNull="false" UpdateCheck="Never" />
<Column Name="SystemId" Member="SystemId" DbType="Int NOT NULL" UpdateCheck="Never" />
<Column Name="UserName" Member="UserName" DbType="NVarChar(50) NOT NULL" CanBeNull="false" UpdateCheck="Never" />
<Column Name="Version" Member="Version" DbType="rowversion NOT NULL" CanBeNull="false" IsDbGenerated="true" IsVersion="true" AutoSync="Always" />
<Association Member="System" Storage="system" OtherKey="Id" ThisKey="SystemId"/>
</Type>
</Table>
</Database>

We can then delete all of our mappings from our domain model so that our model is clean.

    public class Category
    {
        private EntitySet<Category> children = new EntitySet<Category>();
        public int Id { get; set; }
        public string Name {get;set; }
        public int? ParentId { get; set; }
        private EntityRef<Category> parent;
        private EntitySet<ITSystem> systems = new EntitySet<ITSystem>();
        public byte[] Version {get;set;}
        ...
    }

    public class Key
    {
        public int Id { get; set; }
        public string Password { get; set; }
        public int SystemId { get; set; }
        private EntityRef<ITSystem> system = default(EntityRef<ITSystem>);
        public string UserName { get; set; }
        public byte[] Version {get;set;}
        ...
    }

    public class ITSystem
    {
        public int CategoryId { get; set; }
  private EntityRef<Category> category = default(EntityRef<Category>);
        public string Comments {get;set;}
        public string Name {get;set; }
        public int Id { get; set; }
        private EntitySet<Key> keys = new EntitySet<Key>();
        public byte[] Version {get;set;}
        ...
    }

Managing the Mapping File

I often embed the file into the dll that contains the model. The upside here is that you don't need to worry about deployment, but the downside is that you cannot change the mapping without re-issuing the DLL. If you embed the mapping file, you will need some code to read it, so that you can pass it into the DataContext. I use a helper class like this:

    public static class Mapping
    {
        public static XmlMappingSource GetMapping()
        {
            XmlMappingSource mapping;
            using (Stream stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("KeySafeDomain.Mappings.Keysafe.map"))
            {
                mapping = XmlMappingSource.FromStream(stream);
            }

            return mapping;
        }
    }

Then we just grab the mapping when we construct our typesafe DataContext:

        public KeySafeContext() : base(ConfigurationManager.ConnectionStrings[DbName].ConnectionString, KeySafeDomain.Mappings.Mapping.GetMapping())
        {
            Systems = GetTable<ITSystem>();
            Keys = GetTable<Key>();
            Categories = GetTable<Category>();

            DataLoadOptions dataLoadOptions = new DataLoadOptions();
            dataLoadOptions.LoadWith<ITSystem>(s=>s.Keys);
        }

With that done we can re-run our tests to check that everything passes.

Developer Day Ireland

2008-03-06T08:54:00Z

A while back I posted about the future of Developer Day (called DDD here, but not to be confused with Domain Driven Design). For the international audience DDD is was inspired by US Code Camps, and has a similar by and for the community agenda.

One of the issues I raised was that the UK & IE only had one Code Camp event. Although we ran it twice a year, it was always over-subscribed, suggesting that there was a huge demand for on-the-weekend community events. We have always seemed a big enough place to hold a lot more regional events. Back when I last blogged I mentioned DDD Scotland and now I am pleased to note that there will be a DDD Ireland on Saturday May 3rd. It's great to see the community events spreading. It is good to see some ALT.NET topics in the agenda too, Ben is going to be be talking about TDD, Alex Homer (who I guess breaks the rules once he goes to work at the P&P team, but I guess he gets away with it this time around) on Dependency Injection, and Mike Azocar talking about Scrum.

I would still like to see more people across the UK + IE holding local altnet conferences. Come on us Londoners can't have all the fun. They are a lot easier to organize than a DDD style event, as they are mostly self-organizing.

Some recommended books

2008-03-04T12:39:00Z

A couple of people at the BASTA conference asked me for book recommendations for people who were trying to get a better idea of how to do solution design. At the same time, a couple of people at my TDD Best Practices talk at the London .NET user group asked me to remind them about book recommendations. I promised to put the titles we discussed on my blog, so here we go.

This is list is not meant to be exhaustive, but I think it represents a good starting point. I am sure there are many books I have left out that people like, but I wanted to keep the list to a manageable number for people to think about tackling. They are all ones I have found real value in and keep referring to (usually via Safari nowadays).

Design
Head First Design Patterns
Agile Principles, Patterns, and Practices in C#
Patterns of Enterprise Application Architecture
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
Domain-Driven Design: Tackling Complexity in the Heart of Software
Applying Domain-Driven Design and Patterns: With Examples in C# and .NET
Object Design: Roles, Responsibilities, and Collaborations

Test-Driven Development
Test Driven Development: By Example
Working Effectively with Legacy Code
Refactoring: Improving the Design of Existing Code
xUnit Test Patterns: Refactoring Test Code