Think Before Coding - Comments

C# Static interfaces - ferpootoo

ferpootoo — Fri, 10 Feb 2012 01:18:22 +0100

Heh, why not just use the singleton pattern?

public interface IGlobalThing
{

   string Name {get;set;}

}

public class GlobalThing : IGlobalThing
{

   public static GlobalThing Instance = new GlobalThing();

   private string _Name;
   public string Name
   {
       get
       {
           return Instance._Name;
       }
       set
       {
           Instance._Name = value;
       }
   }

   private GlobalThing{}

}

I love SQL Server and cultures... NOT ! - Jérémie Chassaing

Jérémie Chassaing — Mon, 05 Dec 2011 10:21:23 +0100

Thanks for the suggestions. After further tries, I found this to work in any case :

CONVERT(datetime, '2011-12-31 23:59:59.997', 121)

I love SQL Server and cultures... NOT ! - Phil factor

Phil factor — Mon, 05 Dec 2011 00:38:49 +0100

Try using the convert function to convert from string to date, using as a third parameter the convert code appropriate. I've found that one can specify the conversion format exactly. I have found 113 to be generally the safest format, but the convert function accommodates most.

I love SQL Server and cultures... NOT ! - Mike

Mike — Sat, 03 Dec 2011 15:06:27 +0100

You can use the form 'YYYYMMDD' and SQL Server will convert it correctly, regardless of the set culture.

Uniqueness validation in CQRS Architecture - Carol

Carol — Fri, 28 Oct 2011 20:17:07 +0200

Thanks for the article. I've been looking to get more into CQRS since discovering CouchDB and Rinat's (http://abdullin.com/cqrs/) write-up on it. I've implemented a DDD repository pattern that let's you inject either a Hibernate or Couch impl and next I'm going to be writing some Commands against it.

C# Static interfaces - Take 2 - Scott Brickey

Scott Brickey — Fri, 28 Oct 2011 15:48:01 +0200

On multiple occasions, I've wanted an interface to specify specific constructors... after submitting the suggestion to Connect.Microsoft.com I was informed that the constructors are effectively static methods.

So regarding additional use cases for interfaces to specify static methods: Constructors :)

Event Sourcing and CQRS, Dispatch options 2 - Matt Collinge

Matt Collinge — Sun, 02 Oct 2011 21:31:33 +0200

Hi Jérémie, I am enjoying reading through your DDD & CQRS posts, thanks. I just thought that I should point out that your perf test for the AggregateRegisteredOncePerClass is biased by potentially having to go down to Kernel mode due to the lock statement which need only be called if the class has not already been initialised. Your version would have the side effect of making all calls to the .ctor single threaded. With the change below it is ~ 20 times faster than the once per instance option. Again it may be premature optimisation.

public AggregateRegisteredOncePerClass(Guid id)
{
this.id = id;

if(!initialized)
{

lock (ClassInitLock)
{
if (!initialized)
{
initialized = true;
// registration happens only once here
}
}
}
}

Event Sourcing and CQRS, Dispatch options 2 - Bibendus

Bibendus — Sun, 07 Aug 2011 19:33:34 +0200

Hi Jérémie, I found your posts about CQRS very interesting and I would like to ask if you could put the code from your posts somewhere, perhaps on bitbucket along the other code you have there to make it easy to play with it.

Mixing IEnumerable and IQueryable - Bruce

Bruce — Fri, 05 Aug 2011 23:46:58 +0200

Excellent information, not just for improving query performance, but as information on the inner workings of extension methods in general and the gotchas that can go along.

C# Static interfaces - Codernet

Codernet — Thu, 14 Jul 2011 02:29:44 +0200

// Interface we need to make static
public interface IInterface
{
SomeContext Get { get; }
double CalcSum(double a, double b);
}

// static class that acts as "Static Interface"
public static class IStaticInterface
{
private static IInterface _context;

static IStaticInterface()
{
//binder - IoC. Or you could use Factory - doesn't matter
_context = binder.GetDefaultContext();
}

// But if you need to change behaviour you can easily change it with replacing your interface
public static void SetContext(IInterface context)
{
_context = context;
}

// Methods that provide behaviour of your interface
public static SomeContext Get
{
get
{
return _context.Get;
}
}

public static double CalcSum(double a, double b)
{
return _context.CalcSum(a, b);
}
}

I agree that a little code doubling, but i guess you could easy write T4 transformer that would create it.

Event Sourcing and CQRS, Dispatch options 2 - Clément Bouillier

Clément Bouillier — Wed, 22 Jun 2011 22:38:58 +0200

We are not at this stage of maturity, nor in a classic CQRS approach...we use lot of ideas, but not all of them (for now at least...for lots of reason, bad ones or good ones...), that's why we got the problem for sure.
But not so much a problem for us, since solved quite quickly.

We can discuss more in depth at next Alt.Net paris beer of what we are doing...:)

Event Sourcing and CQRS, Dispatch options 2 - Jérémie

Jérémie — Wed, 22 Jun 2011 15:01:33 +0200

@clement> But do those few seconds have a meaning ?
You gain less than 4 second for 10.000.000 aggregates.
For this number of aggregates you get at least 10x more messages/snapshots to load from disk, deserialize and apply. I think there are more time to get there than on instance creation.

Event Sourcing and CQRS, Dispatch options 2 - Clément

Clément — Wed, 22 Jun 2011 14:52:05 +0200

In our case, we have lot of legacy code and we need to improve performance on meaningful code we started to refactor, until we get a better cache feature (working)...

Note that you can achieve even better performance (if really needed yet, i.e you have "lot of" events raised) using compiled late bound expression rather than MethodInfo.Invoke or Delegate.DynamicInvoke...see http://clem-it.blogspot.com/2009/07... for information on performance of these different solutions

Event Sourcing and CQRS, Let's use it. - GT

GT — Tue, 21 Jun 2011 20:40:11 +0200

Thanks. I guess a document store like RavenDB would enable the persistence of IDs/typed IDs in lieu of an RDBMS. Good info.

Event Sourcing and CQRS, Dispatch options 2 - Jérémie Chassaing

Jérémie Chassaing — Tue, 21 Jun 2011 12:38:08 +0200

@yves> Sure.
That's why Clement proposed to use Expression<Action<T>> for the Register method in that case.

This way you can walk the tree to extract the method info from e => this.OnSomethingHappened(e) lambda.
Using this MethodInfo, you can then invoke the method on the instance when you need it in your Apply method.

For the per instance case, you can rely on dynamic, or use a Delegate base type for action and call DynamicInvoke.

Event Sourcing and CQRS, Dispatch options 2 - Yves Reynhout

Yves Reynhout — Tue, 21 Jun 2011 12:29:10 +0200

One small remark: the "routing to state handler" code is different for the "initialization once per type(class)" case. Your registered Action<T> in the "initialization per instance" case references "this", which would make it unusable AFAIK in the "initialization once per type(class)" case.
Here's a paste of how I'm handling this currently (keeping registration process out of the base class): http://pastie.org/2100733

Event Sourcing and CQRS, Let's use it. - Jérémie

Jérémie — Tue, 21 Jun 2011 10:53:59 +0200

@GT> C# has no syntax for alias types, so you have to do it yourself.
In F# you can just write

type EmployeId = Guid

To use if with frameworks, you usually have to hook to those frameworks type conversion if available.
Since I use my own service bus and my own persistence framework, I don't have this kind of problem, but I know that there is no simple way to do it with Linq2Sql.

For Protobuf.Net v2, I managed to use the new Api to build my own serializer/deserializer conventions that manage this.

Event Sourcing and CQRS, Dispatch options. - Clément Bouillier

Clément Bouillier — Tue, 21 Jun 2011 08:42:06 +0200

Hi Jeremie,

We started with handler registration, but it is surely memory and time consuming to register on each aggregate. Then, we face the same challenges:
- I do not like much adding a parameter to each Apply method and make them static
- considering dynamic and convention based, I do not like the fact that R# says my methods are unused (like too much remove code with this, I do not want to have to think about that, even if I agree with Gilligan when he says we have to understand before coding...) and I do not want to change my method to protected or public...
- as Jonathan and you, I do not like the generic type parameter that is now required on the base aggregate class if you consider Jonathan's approach

I see an other solution :
- RegisterEvent is an instance method, that is called in RegisterAllEvents override as in handler registration, but use a static register inside Aggregate, it will remove redundancy of register (memory and time consuming)
- then, you have registered an "apply" method that apply to one particular aggregate instance (RegisterEvent<SomeEventHappen>(e => this.Apply(e)), so you have to remove the reference to "this" instance, here is the trick: you use same registration process as in convention based solution, but rather than using name convention, you use Expression API to retrieve method name on registered Expression e => this.Apply(e).
Note that you can enforce some convention on method signature. Also you cannot use RegisterEvent<SomeEventHappen>(Apply) since Apply is a delegate, not an expression.

Clément

Event Sourcing and CQRS, Let's use it. - GT

GT — Mon, 20 Jun 2011 18:22:30 +0200

This is a wonderful example, Jérémie.

I like the treatment of the BookId, hiding a Guid behind a Struct. I have a couple of questions:

Question 1: Is there a term for this technique?

Questions 2: As the BookId does not expose its data, how would this be persisted and rehydrated, say if you're using NServiceBus and SQL Server for message transportation and event store, respectively.

Thanks.

Time - Jérémie

Jérémie — Fri, 10 Jun 2011 12:28:06 +0200

And I would add that any event is the consequence of previous events since the start of the system.

The primary event is system start.

And the primary event of all that is...

Big Bang !