Think Before Coding

To content | To menu | To search

Wednesday, March 4, 2009

How *not* to inject services in entities

By Jérémie Chassaing on Wednesday, March 4, 2009, 16:01 - Domain Driven Design

syringeI’ve seen lot of people asking where and how to inject services in entities. The services in question are often repositories by the way…

The response is simple :

 - DO NOT inject services in entities !

- Ok I see, you’re against dependency injection

- NO, I'm not against dependency injection, I use it a lot.

- You can still use a static service locator…

- I avoid service locator when I can, especially when the service locator must be static…

– So you’ll get an anemic object model !

- I don’t think so.

 

Injecting services in entities is wrong

You’ll find me a bit presumptuous, but I say it again : Injecting services in entities is wrong.

Nesting objects is not a problem from an OO point of view, but we’re talking about a special kind of objects, entities.

 

Entities are all about their state management, and this state management can require several objects.

  • Code infrastructure objects like lists or dictionary to handle collection of data,
  • Object oriented constructs to leverage code maintenance techniques like strategies.

Entities don’t have to be classes with public setters and getters… you should even avoid this to keep you entities in a consistent state.

But there is no reason for an entity to keep a reference on a service, since it’s not part of its state.

There are usually three situations in which people thinks they need it :

  • Lazy loads
  • Relations
  • Behavior methods

Let’s review each point…

 

Lazy loads

Sometimes, an entity property is heavy to load and is not required by all code paths. In this case, loading it upfront can lead to performance problems.

The usual way to work it out is to hold a reference to a data access object or a repository and to load and cache the requested data on demand.

 

 Using a data access layer object in the entity is clearly a break of persistence ignorance, but using a repository is not a better option.

 

The repository is a way to abstract persistence in the model, but it’s still a persistence concern even if modeled in terms of domain terms.

I’ve already posted about ways to solve this problem in Lazy load and persistence ignorance and part 2.

 

Relations

I was twitting yesterday with Kyle Baley about the need to have an Event repository in the Users entity. He wanted to get the User Team for the current event. I think you don’t need more context to understand the problem.

The User did not know about the current event so it needed the Event repository to find it and find the corresponding team.

But why does the User entity expose a CurrentTeam property if it doesn’t know about Events ? There’s something missing here.

The whole picture becomes clearer if you add a Participant entity that embodies the participation of a user to an Event, and no repository is needed anymore since you don’t need a CurrentTeam property on User.

 Make relations clear instead of hiding it in repositories.

 

Behavior methods

If I have mail message entity and I want a Send method on it ?

Tiding your entity to the service that will use it is not conceptually satisfying. The server that will send the message is a medium and is not part of the entity itself.

It’s seems better to call server.Send(message).

The problem is that you can end breaking the tell don’t ask principle because the Send method will ask the message for each property value. And you can be tempted to put computations that should be in the message entity inside the Send method.

 

Let’s call Double Dispatch to the rescue !

  • Design a server interface presenting a Send method that take the parameters it need (title, recipients, message body…)
  • Add a SendThrough method to your entity that takes the server interface as parameter
  • Implement SendTrhough so that it computes values to pass to the Send method
  • That’s it.

 

Here is a small sample implementation :

    public interface IMailService

    {

        void Send(string sender, string recipient, string subject, string body);

    }

 

    public class Message

    {

        //...

        public void SendThrough(IMailService mailService)

        {

            string subject = isReply ? "Re : " + title : title;

            mailService.Send(sender, recipient, subject, GetMessageBody(content));

        }

    }

The entity is not tied to the service before needed. So no need for injection.

 

Is injection useless ?

There is no problem to inject services with other services, and it’s even easier since services have no state, they only need their dependencies in constructor, and to my opinion it’s the cleanest injection mode.

Usually domain services will need infrastructure services dependencies, and in this case a dependency injection framework can make things easier.

Following the preceding advice, you’ll never need to use your dependency injection framework as a service locator, and you’ll never have to perform buildups on your entities, and you’ll feel much better.

 

What’s your way to deal with it ?

For now I’ve always find a way to get rid of services inside entities, but I really would like to hear cases where you’re stuck with it to see if another way is possible, or cases where you think there is really a good reason to go this way.

20 comments no trackback

Tuesday, February 24, 2009

Domain Driven Design Step By Step

By Jérémie Chassaing on Tuesday, February 24, 2009, 15:57 - Domain Driven Design

Casey Charlton is moving his DDD series on a wiki site so that every body can put it’s personal touch.

You can find it and participate at : http://dddstepbystep.com/

Expect me to write there !

no comment no trackback

Monday, February 23, 2009

Back on track

By Jérémie Chassaing on Monday, February 23, 2009, 09:55

Everything should be back to normal now, the adresses of the feeds have not changed, so no there's no change for you.

no comment no trackback

Sunday, February 22, 2009

Maintenance

By Jérémie Chassaing on Sunday, February 22, 2009, 23:31

I've been moving the blog address from www.thinkbeforecoding.com to thinkbeforecoding.com and it can cause some temporary troubles with the feeds between 2009-02-22 and 2009-02-23.. all should be ok then.

I don't know why Google MyBrand has changed the CNAME redirection inbetween...

no comment no trackback

Tuesday, February 17, 2009

Implement Linq to Objects in C# 2.0

By Jérémie Chassaing on Tuesday, February 17, 2009, 15:55 - Linq

I’m still working mainly with Visual Studio 2005 at work, and I was really missing Linq to Objects features. And I’m sure I’m not the only one.

There are workarounds when compiling C#2.0 code using Visual Studio 2008 since it’s using the C#3.0 compiler internally, but it won’t work in VS2005.

 

How does linq to objects work ?

Linq to Object works by chaining operations on the IEnumerable<> interface.

When writing the following the following linq query statement

   var paperBackTitles = from book in books

           where book.PublicationYear == 2009

           select book.Title;

The compiler translates it to :

  IEnumerable<string> paperBackTitles = books

   .Where(book => book.PublicationYear == 2009)

   .Select(book => book.Title);

 

The lambdas are used as simple delegates in Linq to Object using the following definitions :

 public delegate TResult Func<T,TResult>(T arg);

 public delegate TResult Func<T1,T2,TResult>(T1 arg1, T2 arg2);

 //...

 public delegate bool Predicate<T>(T arg);

 

 public delegate void Action<T>(T arg);

 public delegate void Action<T1,T2>(T1 arg1, T2 arg2);

 //...

So the preceding code is equivalent to :

  IEnumerable<string> paperBackTitles = books

   .Where(delegate(Book book){return book.PublicationYear == 2009;})

   .Select(delegate(Book book){return book.Title;});

But the IEnumerable<> interface doesn’t provide those methods. These are actually extension methods defined in the Enumerable class.

  public static class Enumerable

  {

    public static IEnumerable<T> Where<T>(

               this IEnumerable<T> source,

               Predicate<T> predicate);

    public static IEnumerable<TResult> Select<T, TResult>(

               this IEnumerable<T> source,

               Func<T, TResult> projection);

    //...

  }

 

The translation is immediate :

  IEnumerable<string> paperBackTitles =

     Enumerable.Select(

       Enumerable.Where(books,

          delegate(Book book)

           { return book.PublicationYear == 2009; }),

          delegate(Book book) { return book.Title; });

Once we’re here, there’s nothing that cannot be implemented in C#2.0.

 

What do we need ?

There is plenty of things in Linq to Object, and I prefer to say right now that we will not have the full integrated query syntax !

Implementing the static Enumerable class is not very difficult, let’s provide a implementation for Where and Select :

  public static class Enumerable

  {

    public static IEnumerable<T> Where<T>(

                     IEnumerable<T> source,

                     Predicate<T> predicate)

   {

      if (source == null)

        throw new ArgumentNullException("source");

      if (predicate == null)

        throw new ArgumentNullException("predicate");

 

      return WhereIterator(source, predicate);

   }

 

   private static IEnumerable<T> WhereIterator<T>(

                            IEnumerable<T> source,

                            Predicate<T> predicate)

   {

      foreach (T item in source)

        if (predicate(item))

          yield return item;

   }

 

   public static IEnumerable<TResult> Select<T, TResult>(

                            IEnumerable<T> source,

                            Func<T, TResult> projection)

   {

      if (source == null)

        throw new ArgumentNullException("source");

      if (projection == null)

        throw new ArgumentNullException("projection");

 

      return SelectIterator(source, projection);

   }

 

   private static IEnumerable<TResult> SelectIterator<T, TResult>(

                              IEnumerable<T> source,

                              Func<T, TResult> projection)

   {

      foreach (T item in source)

         yield return projection(item);

   }

 

    //...

}

You can notice that I’m splitting the methods in a part that does argument check and another one that makes the actual iteration process. This is because the iterator code will only get called when actually iterating, and it will be really hard to find out why the code throws an exception at that moment. By performing argument checking in a non-iterator method, the exception is thrown at actual method call.

 

Since C#2.0 doesn’t support extension methods we’ll have to find something so that the code doesn’t look ugly as in the final translation above.

 

Simulating extension methods in C#2.0

Extension methods are just syntactic sugar and are simply converted to a static method call by the compiler :

  books.Where(predicate)

  // is translated to

  Enumerable.Where(books, predicate)

If we can wrap the books variable in a kind of C++ smart pointer providing the Where method, the trick is done.

To do this, we will use a small struct that encapsulate the IEnumerable<> interface :

  public struct Enumerable<T> : IEnumerable<T>

  {

     private readonly IEnumerable<T> source;

 

     public Enumerable(IEnumerable<T> source)

     {

        this.source = source;

     }

 

 

     public IEnumerator<T> GetEnumerator()

     {

        return source.GetEnumerator();

     }

 

     IEnumerator IEnumerable.GetEnumerator()

     {

        return GetEnumerator();

     }

 

     public Enumerable<T> Where(Predicate<T> predicate)

     {

        return new Enumerable<T>(

            Enumerable.Where(source, predicate)

        );

     }

 

     public Enumerable<TResult> Select<TResult>(

                       Func<T, TResult> projection)

     {

        return new Enumerable<TResult>(

            Enumerable.Select(source, projection)

         );

     }

 

     //...

}

The return type is Enumerable<> so that calls can be chained.

 

We can had a small helper to make the smart pointer creation shorter :

  public static class Enumerable

  {

    public static Enumerable<T> From<T>(

                    IEnumerable<T> source)

    {

       return new Enumerable<T>(source);

    }

    //...

}

Now we can write :

  IEnumerable<string> paperBackTitles =

    Enumerable.From(books)

     .Where(delegate(Book book){return book.PublicationYear == 2009;})

     .Select<string>(delegate(Book book){return book.Title;});

We just have to extend the Enumerable class and Enumerable<> struct with more methods to get a full linq to object implementation in C# 2.0.

9 comments no trackback

Sunday, February 8, 2009

Lazy loads and persistence ignorance (Part 2)

By Jérémie Chassaing on Sunday, February 8, 2009, 13:17 - Domain Driven Design

In the previous post, I introduced a class to manage function injection for lazy loads to enable persistence ignorance.

Chris was asking where the builder I was talking about should be used, and I tumbled on a StackOverflow question asking how to make lazy loading without using classes like Lazy<T>...

I'll discuss the second part first.

There is a good way to make lazy loading without using classes like that. You can use proxies.

There are two main ways to make transparent proxies

  • by creating dynamically a derived class using Reflection.Emit
  • by creating a transparent proxy

Still there are some drawbacks with both approaches. For the first one, all your members should be made virtual, for the second your class should inherit from MarshalByRefObject. In all case you should then take care not to mess up between proxies and underlying classes.

The main critic to refuse to use Lazy<T> class is usually that it's not a domain concept, and that it leaks persistence concern in the model.

I reject those critics.

Have you ever seen someone criticize List<T> or Dictionary<,> because it was not a domain concept ? We're writing OO code, and we can use basic tooling to make our models expressive. IEnumerable<T> and Linq to objects are good examples of these useful tools.

And I don't consider that Lazy<T> is a persistence concern. It expresses that the relation between entities is a bit more loose than others. There is nothing in the Lazy<T> signature that ties your entity to any persistence concept. You just provide a way to give the value of the property when needed rather than at construction, but this choice comes from outside of your entity.

And at least it becomes clearer than with derived proxies where the C# keyword virtual is used to express something but tries to hide it in the same time.

 

For Chris question, I use the builder in the repository.

The repository is responsible for retrieving entities from the data store. The reconstruction of objects is a bit different from the construction. This is underlined in Evan's book in the chapter Factories / Reconstituting Stored Objects.

In my data access layer I use a IDataBuilder<T> interface that represents a service that can build an object of type T from a IDataRecord. This is when I work directly with the ADO.Net and stored procedures.

    public interface IDataBuilder<T>

    {

        T Build(IDataRecord record);

    }

 

I also use a class that encapsulate the access to the stored procedures (or queries if you don't want to use stored procedures).

    public class DataAccess

    {

        public UniqueResult<Entity> GetEntity(Guid id);

        {

            //...

        }

 

        public MultipleResult<Entity> GetEntities()

        {

            //...

        }

    }

 

UniqueResult<T> and MultipleResult<T> provides a methods that take a builder to read data records :

    public struct UniqueResult<T>

    {

        public T With(IDataBuilder<T> builder)

        {

            //...           

        }

    }

 

    public struct MultipleResult<T>

    {

        public IEnumerable<T> With(IDataBuilder<T> builder)

        {

            //...           

        }

    }

 

In your repository implementation you can then use all this :

    // The concrete repository interface that belongs to the domain

    public interface IEntityRepository : IEnumerable<Entity>

    {

        Entity this[Guid id] { get;}

        //.. other methods

    }

 

    // the implementation that is not part of the domain

    // an that is pesistance dependant.

    internal class EntityRepository : IEntityRepository

    {

        private DataAccess dataAccess;

        private EntityBuilder builder;

 

        public EntityRepository(DataAccess dataAccess, EntityBuilder builder)

        {

            this.dataAccess = dataAccess;

            this.builder = builder;

        }

 

        public IEnumerator<Entity> GetEnumerator()

        {

            return dataAccess.GetEntities().With(builder);

        }

 

        IEnumerator IEnumerable.GetEnumerator()

        {

            return GetEnumerator();

        }

 

        public Entity this[Guid id]

        {

            get { return dataAccess.GetEntity(id).With(builder); }

        }

    }

 

The last part is in the implementation of the builder.

    internal class EntityBuilder : IDataBuilder<Entity>

    {

        private DataAccess dataAccess;

 

        public EntityBuilder(DataAccess dataAccess)

        {

            this.dataAccess = dataAccess;

        }

 

        public Entity GetEntity(IDataRecord record)

        {

            var id = (Guid)record["Id"];

            return new Entity(

                id,

                Lazy.From(() => dataAccess.GetSubEntity(id)));

        }

    }

 

Of course, the repository implementation, the DataAccess class and the builder are all internal to the data access implementation. It can be in a separate Assembly or internal in a sub namespace of the main assembly depending on you module separation preferences.

When using linq, you simply don't need the DataAccess class because you can query the DataContext directly. But you can use the same pattern.

The main point is still that your Entity object knows strictly nothing about what's going on there.

7 comments no trackback

Saturday, February 7, 2009

Lazy load and persistence ignorance

By Jérémie Chassaing on Saturday, February 7, 2009, 14:44 - Domain Driven Design

lazy

I often see questions about how to make lazy loads in entities, and wether using dependency injection for it.

The usual response is something like this :

    class Entity

    {

        private Guid id;

        private SubEntity subEntity;

        private IDataService dataService;

 

        public Entity(Guid id, IDataService dataService)

        {

            this.id = id;

            this.dataService = dataService;

        }

 

        public SubEntity SubEntity

        {

            get

            {

                if (subEntity == null)

                    subEntity = dataService.GetSubEntity(id);

 

                return subEntity;

            }

        }

    }

As you can see, your entity is seriously tied to your persistence problem now. Even if it accesses the persistence layer through an interface, it is not persistence ignorant anymore.

The smell is that you cannot create an in memory instance of your entity anymore without worrying about data access.

Should you sill inject the data access service, or is it useless and you should leave it null ?

So believe me : do not inject data services in your entity.

Now, how can we still have the lazy load behavior ?

Through injection. But not dependency injection, I use execution inversion of control through delegate injection.

If you give to your entity a function that will return the value when asked, it's as if you gave the value.

Let's encapsulate this in a small class :

    public class Lazy<T>

    {

        private T value;

        private Func<T> loader;

 

        public Lazy(T value)

        {

            this.value = value;

        }

 

        public Lazy(Func<T> loader)

        {

            this.loader = loader;

        }

 

        public T Value

        {

            get

            {

                if (loader != null)

                {

                    value = loader();

                    loader = null;

                }

                return value;

            }

        }

 

        public static implicit operator T(Lazy<T> lazy)

        {

            return lazy.Value;

        }

 

        public static implicit operator Lazy<T>(T value)

        {

            return new Lazy<T>(value);

        }

    }

Then you can use it like this in your entity :

    class Entity

    {

        private readonly Guid id;

        private readonly Lazy<SubEntity> subEntity;

 

        public Entity(Guid id, Lazy<SubEntity> subEntity)

        {

            this.id = id;

            this.subEntity = subEntity;

        }

 

        public Guid Id { get { return id; } }

 

        public SubEntity SubEntity

        {

            get { return subEntity; } // implicit cast here

        }

    }

The code is more straight forward, the intent is clearly visible.

One benefit here, is that the subEntity field can be marked as readonly, that is a big improvement because our entity is really immutable now. Actually the Lazy<T> is mutable, but it behaves as an immutable value.

If your entity is not immutable, you can still leverage the Lazy<T> class :

    class Entity

    {

        private readonly Guid id;

        private Lazy<SubEntity> subEntity;

 

        public Entity(Guid id, Lazy<SubEntity> subEntity)

        {

            this.id = id;

            this.subEntity = subEntity;

        }

 

        public Guid Id { get { return id; } }

 

        public SubEntity SubEntity

        {

            get { return subEntity; } // implicit cast here

            set { subEntity = value; } // implicit cast here too

        }

    }

The last part is about how you use it when instantiating the object.

When creating a new instance in a factory (not linked to database) :

            SubEntity subEntity = ...;

            Guid id = ...;

            Entity entity = new Entity(id, subEntity);

Here again, the implicit cast happen to pass the SubEntity as an already loaded Lazy<SubEntity>.

When binding the entity to the database :

    class EntityBuilder

    {

        private IDataService dataService;

 

        public EntityBuilder(IDataService dataService)

        {

            this.dataService = dataService;

        }

 

        public Entity GetEntity(Guid id)

        {

            return new Entity(

                id,

                new Lazy<SubEntity>(() => dataService.GetSubEntity(id)));

        }

    }

We can use a small helper method to make the instantiation cleaner :

    public static class Lazy

    {

        public static Lazy<T> From<T>(Func<T> loader)

        {

            return new Lazy<T>(loader);

        }

    }

Then you can write :

            return new Entity(

                id,

                Lazy.From(() => dataService.GetSubEntity(id)));

 

Now, the code that instantiate the Entity decides where the sub entity comes from.

The entity has become truly persistence ignorant.

Some would also advice not to use lazy load at all... this is still an option to consider !

Continued in Lazy loads and persistence ignorance (Part 2)

8 comments one trackback

Wednesday, January 21, 2009

Mixing IEnumerable and IQueryable

By Jérémie Chassaing on Wednesday, January 21, 2009, 17:12 - Domain Driven Design

Marcel posted a comment in the previous post saying that even if returning IEnumerable, the new query clauses would be executed in the database… But it’s not.

If the repository use linq internally and returns the result as IEnumerable, on the other side, consider something like this :

var selectedEntities = repository.GetAll().Where(x => x.Selected)

Where GetAll returns an IEnumerable (that is actually a IQueryable).

The Where extension method will be selected on Enumerable. Be careful, Extension methods are static methods, no virtual call is involved here. The static type of the object decide the selected extension method.

 

Check in your debugger, selectedEntities is an instance of the Enumerable.WhereIterator internal class.

 

So when enumerating it, it enumerates its source and returns every item that passes the predicate.

When enumerating the source, here the source use linq2Sql to get the items and creates a query that returns all rows from the database.

The where clause was not executed in the database.

So the Linq provider did not leak outside of the repository.

2 comments no trackback

Monday, January 19, 2009

Repositories and IQueryable, the paging case.

By Jérémie Chassaing on Monday, January 19, 2009, 11:50 - Domain Driven Design

Edit : My opinion on this subject have changed… You can read the full story in Back on Repositories and Paging. Introducing reporting.

The technique is still useful to write the query services, but I would not recommend to implement it on a repository.

 

When it comes to repositories, people have a hard time figuring how to respect the DDD vision while taking most out of current ORM technologies (Linq and ORM) and not writing too much code – we’re so lazy.civilwar

The war between IRepository<T> generic repositories or not is raging outside, and I took some time to chose my side. Here are the points to consider :

  • The repository is a contract between the domain and the infrastructure
  • The implementation details should not leak outside

In my opinion, the first point indicates that the repository should be tailored to the domain needs. It cannot be generic, or it is not a contract at all.

When writing a contract, details matter !

This doesn’t mean that we cannot use generic tools to access data behind the interface curtain. Linq DataContext and Tables<T> are very sharp tools to implement repositories. And there is a very good post by Greg Young about that.

 

There is still a point to be discussed though :

Should the repository methods return IEnumerable<T> or IQueryable<T> ?

The IQueryable<T> is part of the framework, and cleanly integrated in the language.

The problem is that its implementation depends heavily on the underlying provider. And it is a really serious leak !

So lets state the question differently :

- Why would we need IQueryable ?
 - Because we can add new query clauses, and they will be executed directly in the database.

- What kind of clause would you add ?
 - Don’t know… clauses…

- Would it be business specifications ?
 - No, these should already be in the repository..

- So ?
 - Sorting and Paging ! These are presentation concerns !

- Here’s the point.

Paging is not a recent concern for programmers and there is never enough tools to implement it properly. The main problem is that paging once you’ve got all the data is less that effective. And this is what will happen with an IEnumerable approach.

But let’s ask a two last questions.

Why is paging useful ? Is it really a presentation concern ?

We need paging to navigate through large collection of object, and if a collection can grow enough so that is cannot be embraced in a single query, it becomes a domain concern !

  • When your object collection is known at design time to stay in small bounds but you still want to page it for presentation clarity, there is no real penalty to fetch all and display only a few.
  • But when your collection can grow big, you SHOULD provide a mechanism to retrieve only a range of it, for presentation purpose or simply for batching purpose.

The problem is that if we leak IQueryable, the user can do far more than paging, and problems can arise. So I suggest to use a new interface IPaged<T> that would provide everything needed for paging :

public interface IPaged<T> : IEnumerable<T>

    {

        ///<summary>

        /// Get the total entity count.

        ///</summary>

        int Count { get; }

 

        ///<summary>

        /// Get a range of persited entities.

        ///</summary>

        IEnumerable<T> GetRange(int index, int count);

    }

 

And here is a simple implementation on a IQueryable :

public class Paged<T> : IPaged<T>

    {

        private readonly IQueryable<T> source;

 

        public Paged(IQueryable<T> source)

        {

            this.source = source;

        }

 

 

        public IEnumerator<T> GetEnumerator()

        {

            return source.GetEnumerator();

        }

 

        IEnumerator IEnumerable.GetEnumerator()

        {

            return GetEnumerator();

        }

 

        public int Count

        {

            get { return source.Count(); }

        }

 

        public IEnumerable<T> GetRange(int index, int count)

        {

            return source.Skip(index).Take(count);

        }

    }

Then your repository can return IPaged collections like this without leaking implementation details :

public IPaged<Customer> GetCustomers();

 

This seems to be a major step in the repository pattern understanding, and it’s underlying war. And you, on which side are you ?

18 comments one trackback

Thursday, January 8, 2009

Asp.net MVC binding security issue

By Jérémie Chassaing on Thursday, January 8, 2009, 17:58 - Asp.net

There’s a post on CodeThinked about a serious potential security issue.

The problem comes from an MVC convenience that when using an object as a controller action parameter, Asp.net MVC will bind the form fields to object properties auto-magically. Read the full post for a complete description.

I would recommend a solution using a presentation only model. There is a good reason for this.

The model object passed to the view should not be directly the domain/business object. I always create a thin adaptation layer for presentation, even when it doesn’t add much value. I lets me decouple presentation concerns from domain concerns.

The object coming back from the form should follow the same rule as part of this presentation concerns. There is no problem if those presentation objects provide only non sensitive fields.

 

But it’s sure that not anyone will know about the risks.

no comment no trackback

Monday, December 29, 2008

Asp.Net authentication cookie oddities...

By Jérémie Chassaing on Monday, December 29, 2008, 18:24 - Asp.net

Back to low level considerations.

In order to use a specific and shareable encryption scheme between sites, we had to bypass the FormsAuthentication.Encrypt method an write a new one.

Something strange happened then. When using our implementation, the cookie disappeared !

The cookie was added to the Response.Cookies, but was not present in the Request.Cookies of the following request.

After deep search, it appeared that the cookie was actually sent to the browser. Why wouldn’t it be sent back ?

The really weird thing was that the cookie data was in the Response.Headers, but not in Response.Cookies !!!

It seems that when parsing the Cookie header, Asp.net strips off the .ASPXAUTH cookie if it cannot be decrypted by FormsAuthentication.Decrypt !

The solution was to use another cookie name, and everything was working again !

If it can save 2 hours of your precious time…

no comment no trackback

Wednesday, December 24, 2008

Data Structures and Algorithms

By Jérémie Chassaing on Wednesday, December 24, 2008, 11:05

I had a peek through Jon Skeet’s blog this morning at a free eBook called Data Structures and Algorithms by Granville Barnett and Luca Del Tongo.

The book is clear and presents the usual linked lists, trees, sets structures in a concise yet precise way.

There’s something new I had not seen in other algorithm books before. The algorithms are written in pseudo code, but there is a chapter about unit testing your implementation.

If the writers read this, I just would like to share a little tricks that make linked list algorithms easier to write..

Linked list algorithms are always bloated with tests like this :

        if (head == null)

            head = ...;

        else

            node->Next = ...;

Actually the content of head and then content of node->Next are both pointers on next node. But the way to reference those two locations is different, ending in a lot of if statements.

If the language supports reference variables or pointer, you can use a double pointer to hold the current position :

Node** next = &head;

This way there is no more difference between the head (*next) and nodes Next pointers. The little tricky thing is to move to next location :

next = &((*next)->Next);

With this you can consider every ‘Next’ pointer including head as equivalent. No more if statement !

By the way, I was trying to find out how to do this on C#, but is it possible without going unsafe ?

no comment no trackback

Monday, December 22, 2008

DDD: Specifications

By Jérémie Chassaing on Monday, December 22, 2008, 16:42 - Domain Driven Design

There's an interesting post by Greg Young about Specifications.

I'm currently refactoring some code to move constraints and validation in specification classes, and it really gives a better insight at what is constituting entities and what's not, especially when there are multiple level of constraints (persistence constraints, business constraints...)

no comment no trackback

Friday, December 19, 2008

Coding and writing - The form

By Jérémie Chassaing on Friday, December 19, 2008, 16:26

There is a number of common points between coding and writing

Spelling

The most basic mistake... Oops I wrote retrun instead of return... hopefully modern text editors check it on the fly.

Syntax

Correct sentences are made of word in a correct order. Here again, on the fly checking helps a lot.

Presentation

Is your code visibly clear... Enough space between parts, but not too much. Is you code clearly indented.

Style

Style is even more subjective. When coding, usually stay concise, but there are a lot of parameters here.

You can :

  • choose if statements or ?: alternating operator
  • define fluent interfaces to do things on several lines
  • use linq to express your intent more clearly,
  • use var implicit type or not
  • use anonymous types or not
  • use lambdas or functions

The important thing is that your style should fit some purpose, the style should emphasis important parts of your primary intent.

Structure

A book is divided in parts, chapters and paragraphs. The code is divided in files namespaces and classes. The structure of the code should help the reader go straight to what is the most important to him and understand how things are related.

 

Next time, we'll talk about substance. Tell me if you see more analogies !

no comment no trackback

Wednesday, December 10, 2008

Wow - Book review - Domain Driven Design!

By Jérémie Chassaing on Wednesday, December 10, 2008, 12:46 - Domain Driven Design

Ok, I finished Domain Driven Design yesterday. I think I had no such Aha moment since I read Design Patterns eleven years ago...

I thought I was prepared for it, I had read many things to get maximum info...

I had :

I had practiced knowledge crunching on my own for long.

But the book go far beyond all that. It has a deep vision of programming on large scale projects, and give really good insight on difficulties that arise when working on complex systems with several teams. These are really precious pieces of advice.

The pattern presentation of the different chapters, even when those patterns are not implementation patterns but team organization patterns is really helpful and clear.

There is not much about implementation details, but it is not a problem. The principles are not tied to a specific technology or framework. Actually this is even a good point, it leaves the book clean from a specific implementation. Implementation books are aging faster.

You definitely should have this book on your shelf.

no comment no trackback

Tuesday, December 2, 2008

Domain Driven Design

By Jérémie Chassaing on Tuesday, December 2, 2008, 14:41 - Domain Driven Design

I had read a lot of stuff about it these last months, and I think I got the essence and the principles.

I've received the blue book today.

I'm sure I'll have matter for blogging these days...

no comment no trackback

Monday, December 1, 2008

Problem with the Select N+1 problem

By Jérémie Chassaing on Monday, December 1, 2008, 16:17

Ayende proposes solutions for the Select N+1 problem in NHibernate.

Some will say it is a sign that lazy load is the work of the devil. But I can remember the time when people were saying that garbage collectors are evil.

We all would like to have non intrusive data fetching strategy that work 99% of the time !

The problem is not about lazy load or not. It is that you must take care about your data fetching strategy whenever you make a data access.

There is currently no technology smart enough to infer the right fetching strategy.

If someone builds it, this won't be a problem anymore.

If you know about it, please tell the world !

no comment no trackback

Ubiquity of language... lost in translation ?

By Jérémie Chassaing on Monday, December 1, 2008, 10:49

I found two collapsing problems :

  • You should use the same language between domain experts and development teams (DDD)
  • You should use English for naming in your code (Design guidelines)

What if my domain experts don't speak English ?

3 comments no trackback

Tuesday, November 25, 2008

CSS is too Tricky

By Jérémie Chassaing on Tuesday, November 25, 2008, 16:47

I found through Alvin Ashcraft's Morning Dew a post about CSS tricks Six indispensable CSS tips and tricks I use on every project. Very interesting since it gives some ways to make cleaner CSS integration (I really like the Overclear one, don't need the clear both anymore !!).

But while reading this question came to my mind:

Why do we need to find crazy tricks like this for any single thing we want to do with HTML + CSS ?

This is the sign that HTML + CSS is a complete design failure !

When you want to make something as simple as putting several blocks on the same line... you must use float left, but it does not behave exactly has you expect it to do... When using Silvelight and WPF I had none of these problems. There are surely other problems with theses technologies but I have found an important difference :

  • In CSS, the elements decide how the fit in their parent
  • In Silverlight, parents decide the layout of their children

And it makes a huge difference. Because in CSS, the interactions between sibling children using very different placement models make it a n*n combination problem. For sure it's not manageable and no browser can handle every case gracefully.

In Silverlight, you obtain the layout you want by composition, and each rule remains simple. No need to use Jedi tricks to obtain what you want.

2 comments no trackback

Monday, November 24, 2008

Coincidences just happen...

By Jérémie Chassaing on Monday, November 24, 2008, 15:51

It's quite strange how ideas can appear at the same time in different places. This morning while take a shower I was thinking about a future post series about programming and building architecture and how things had changed in the last few years. Only 1h later I was reading this post by Justin Etheredge, that matches exactly this subject.

I'm still preparing the posts however.

no comment no trackback

- page 3 of 4 -