In a typical WCF service, you’ll have one or more Service Contracts, and each Service Contract will define one or more Service Operations. These operations are just methods that you can call on the service. An operation can have parameters and it can have a return value. Most people typically expose multiple operations on their services for each piece of functionality they want their service to offer to consumers.

The Request/Response Service Layer (RRSL) takes a different approach. It has one service contract, with only one operation defined:

Notice the lack of the typical WCF attributes such as ServiceContract and OperationContract. The RRSL is actually completely independent from WCF and only uses WCF as a transport medium. That’s the topic of another post though, so let’s get back to the topic at hand: requests and responses.

As you can see, the Process method receives an array of Request objects and returns an array of Response objects. So what exactly is a Request and what is a Response? This is what they look like:

Both are classes that you should derive specific Request and Response types from. The Response class automatically comes with an ExceptionInfo class (which is pretty much identical to WCF’s ExceptionDetail class and only exists because Silverlight 2 did not support ExceptionDetail) and an ExceptionType enum:

The ExceptionInfo class (or ExceptionDetail if you would prefer to use that) does not contain the original Exception object, so the ExceptionType enumeration can be used to handle each type of exception differently on the client-side. Obviously, if a Request was handled without problems, the ExceptionInfo property of its Response will be null, and the ExceptionType property will be set to ExceptionType.None.

The idea is basically that instead of defining operations on your services, you create a specific Request class and a corresponding Response class for each operation that you would normally expose on your service. The request type is the operation, its properties are the operation’s parameters and the Response type is the operation’s return value. Note that you can define multiple properties on your Response types, effectively giving you the ability to support multiple return values for an operation without having to use out parameters.

A simple example of a Request and its Response can look like this:

Note that by default, if you’re using at least .NET 3.5 SP1, you do not need to mark your Request/Response types as Serializable or apply the DataContract/DataMember attributes on them if the assembly containing the Request/Response types can be shared between both your service and your clients. If your service needs to be interoperable with other platforms or you can’t share the assembly containing the types, then you obviously do need to use the DataContract/DataMember attributes but if you’re only communicating with .NET clients and you can share the assembly, it’s not needed. Provided that all of the clients also use at least .NET 3.5 SP1 obviously.

At this point you might be wondering: “what exactly is the benefit of doing this?”. Well, at this point in the series there is only one benefit that you can see already: the fact that the Process method of the service receives an array of requests and returns an array of corresponding responses. That means that you can easily send multiple requests to the service with only one roundtrip, which can greatly reduce the network communication overhead that you can otherwise suffer with typical Service Contracts, especially if their interface is too chatty.

There are many more benefits to using the RRSL, but you’ll have to read the rest of the posts in the series to learn about those

I wrote a post a couple of months ago to discuss what i dislike about typical/classic WCF services and how the RRSL solves many of those issues. If you haven’t read that post yet, be sure that you do because i’d rather not repeat the thoughts from that post (yet again ) and it’ll definitely help you understand some of the choices and decisions that influenced the RRSL.

These are the posts that this series consists of:

1. Requests And Responses
2. Processing Requests
3. Handling Requests
4. Exposing The Service Layer Through WCF
5. Synchronous Client-Side Usage
6. Testing Synchronous Client-Side Usage
7. Asynchronous Client-Side Usage
8. Testing Asynchronous Client-Side Usage
9. Conclusions

Note: the links to the posts will be updated as the posts are scheduled.

Note: All of the code shown in this series may be reused under the terms of the Creative Commons Attribution 2.0 License.

I don’t really have a problem with Twitter, but it’s just not right for me. For one, my opinions and statements often need quite a bit of clarification and context if i don’t want them to be misconstrued. Hell, i often write longish posts to clarify them and even then there are still quite a few people who still misinterpret things. If i’d post them in tiny blurbs on Twitter, i’d probably end up wasting quite a bit of time in follow-up discussions to try to clear things up. So when it comes to communicating my thoughts, it’s definitely not right for me.

When it comes to following other peoples’ thoughts, the situation is even worse IMO. I looked over the twitter pages of a number of developers who’s blogs i read and enjoy and frankly, the occasionally interesting tweets are far, far outnumbered by a lot of stuff that i’m simply not interested in. I honestly don’t care about your personal life unless you’re a friend of mine. I don’t need to know how much you hated being stuck in traffic this morning (and why on earth would i want to look at a picture of it?). I don’t need to know how great the date was you had last night. I don’t need to know how much you enjoyed the latest episode of House M.D. I don’t need to know what album or song you’re enjoying at the moment. I don’t need to know about the crappy meeting you just had or the fact that you didn’t get what you wanted from it. I certainly don’t need to know about the mess your cat left next to your keyboard and i really, really don’t need to know about your bowl movements either. I’m not really interested in all of the sucking-up-to-the-cool-kids-while-they-pretend-not-to-care either, we are after all no longer in high school.

It’s too bad really, because the interesting tweets that you do come across can definitely be worthy of discussion or conversation. But twitter has got to have the lowest signal-to-noise ratio that i’ve ever seen on the internet and i hardly have enough time to work on the things that i want to work on, let alone spending time going through a bunch of tweets every day to find the occasionally good one. Again, that’s just my personal opinion. If you use and enjoy twitter, that’s great! But it’s just not for me.

First of all, you need to make sure that your IIS installation has support for Windows Authentication. Go to Add/Remove Programs (appwiz.cpl), click on Turn Windows Features on or off, select Internet Information Services – World Wide Web Services – Security and make sure that Windows Authentication is checked.

Next, you need to make sure that the virtual directory where you’re hosting the WCF service has Windows Authentication enabled. Open Internet Information Services Manager (inetmgr), select the virtual directory where the WCF service is hosted, click on the Authentication icon and enable Windows Authentication.

After that, you need to add the following to the binding configuration of the service endpoint (in the host, obviously):

I only got it working with basicHttpBinding, so unfortunately i can no longer use the customBinding to use binary XML…

In your Silverlight project, open the ServiceReferences.ClientConfig file and add the following to the binding configuration:

After that, you should be able to do this in your WCF service:

And that should return the Windows user of the user running the Silverlight client.

For the record: this is with Silverlight 3… i have no idea if it’ll work with Silverlight 2

This example is very abstract, but it should be pretty clear. Constructor injection is used to inject the required dependency whenever an instance of MyService is created, whereas setter injection is used to inject the optional dependency after the instance is created. I obviously can’t speak for everyone who uses Dependency Injection, but generally speaking most people use constructor injection for required dependencies and setter injection for optional dependencies.

There is however one situation in which i prefer setter injection for required dependencies over constructor injection: dependencies of abstract classes or base classes. For instance, in our service layer each incoming request is handled by a specific RequestHandler. Most of our RequestHandlers need our NHibernate infrastructure to be set up, which is automatically taken care of by our UnitOfWork implementation. So we have the following NhRequestHandler class (simplified for the purpose of this blog post):

As you can see, the IUnitOfWork dependency is a required dependency because you would get a NullReferenceException when trying to handle a request without having a IUnitOfWork instance present. Yet, i really don’t want to put it in the constructor because then each and every RequestHandler that derives from this will also have to put it in the constructor, even though most of them won’t access the IUnitOfWork directly.

Actually, most of our applications inherit from the NhRequestHandler and then add some more dependencies that some kind of base BusinessRequestHandler will need. These are dependencies to deal with authentication, authorization, user context, application context, etc… Some of these dependencies will be used by the derived RequestHandlers, some won’t. All of them however will indeed be used by the BusinessRequestHandler so they are definitely required dependencies. Using constructor injection for these dependencies would lead to ‘noise’ in every derived RequestHandler’s constructor.

Instead, we use setter injection for all of a base-type’s dependencies, and use constructor injection only for the dependencies of the derived types. It keeps the constructors as clean as they can be and avoids unnecessary noise. We know that our IOC container will fulfill all the constructor dependencies as well as each property dependency in the inheritance hierarchy so there’s no chance of anything going wrong there. Unless of course somebody seriously breaks the IOC configuration but in that case, our applications won’t even make it through the simplest of requests so that’s not something that will ever happen unnoticed.

And for our tests, we always inherit our fixtures from things like HandlerTest or ControllerTest or whatever where all of those property dependencies are automatically set up with mocks or stubs, so it doesn’t really cause problems there either.

But the best part of it is that i also upgraded to the newly released VMWare Fusion 3. As some of you already know, i use my Mac for all regular computer usage, and i use a virtual machine to run Windows which i only use when i’m doing .NET development at home. I was still using a virtualized Windows XP on my MacBook because for one, i can’t stand Vista and i figured it would be way too slow to run in a virtual machine on the MacBook anyway. But for the past 2 months or so, i’ve been using Windows 7 at work and much to my surprise, i’m actually very happy with it. It’s still butt-ugly, but at least it runs nicely, it’s fast, it’s stable, and it hardly ever annoys me. It’s like Windows 2000 all over again :p. So i figured it was time to make the switch at home as well. So now i have a virtual Windows 7 with Visual Studio 2008 running on the iMac (only when i wanna do .NET stuff obviously) and it’s running very well. Performance is really unbelievable, considering that it’s virtualized and i only gave the VM 2GB of RAM. I did disable Aero (i could use it, but the difference was noticeable) but i kept the typical new Windows look, if only because the classic look is even worse.

While writing code at home had become more of a chore than a joy because of the slowness of running a virtual Windows XP on the MacBook, it’s now really enjoyable again

1. The Life And Times Of A Bug

   This is definitely my nr 1 favorite post. I guess it was a bit too far out there for most people but you have to admit at least one thing: you’ve never read anything like that before :p

2. Ethics In Software Development: Pragmatism Over Dogmatism

   Dogmatism of any kind is wrong. Pragmatism isn’t always ideal either, but a healthy balance between them is a necessity in this business.

3. Buzzword Driven Development Isn’t Gonna Help You

   I hate it when people go overboard with buzzwords, and it shows in this post.

4. Make It Work, Make It Clean?

   I really loved this post… it’s about an approach that one of my friends used (and still uses from time to time). I certainly don’t recommend this approach to anyone because i can only imagine a handful of people pulling this off successfully, but it’s interesting nonetheless.

5. Test Doubles: When To (Not) Use Them

   I actually think this is pretty good advice about when to use test doubles, and when not to. Unfortunately, hardly anyone read it

6. Which Path To Follow?

   Which path should one follow if one is merely looking to improve continuously?

7. Thoughts on code reviews

   Discusses a different approach i once took for a code review.

8. Is SQL going the way of Disco?

   People are writing less and less SQL… my question was: why should they?

9. Are women better developers than men?

   If the majority of male developers sucks, is it a stretch to think that maybe women on average would be better at it than we are?

10. Programming Languages Don’t Matter

    They really, really don’t.

Hopefully some of you will like a few of these posts now

The problem that i have with exposing a collection’s values through a type which enables other pieces of code to modify the state of that collection is that it is effectively a pretty big breach of encapsulation. You no longer have sole control over the contents of the collection. Anyone can effectively add and remove elements from the collection, or even clear them entirely, without your object knowing about it. Obviously, this can cause subtle side-effects in the behavior of your object. Which can (and sooner or later will) lead to some quality time between you and your debugger. You also no longer have the ability to easily change the type of collection you’re using which might prevent certain future improvements that you can make to a class. And in case you’re wondering why you’d want to change the type of collection, check out an example where the benefit was huge.

In a lot of cases, people do this because they don’t know any better or because it’s the easiest thing to do. I can’t tell you how many times i’ve seen people expose List<T> simply so that some calling code could use the ForEach method of that list. How long does it take to write a ForEach extension method for IEnumerable<T>? Granted, it should’ve been included in the .NET framework already but just because it’s not doesn’t mean you can’t do so.

Here’s my philosophy on exposing collections: if i’m writing a class that is responsible for holding a collection, i take away every ability to directly modify the contents of the collection. I typically expose the collection through an IEnumerable<T> property, and if necessary i will provide a specific AddXxx and RemoveXxx method. That’s it. You can do every single thing you need to do with the collection through IEnumerable<T>’s extension methods and through the AddXxx and RemoveXxx methods that i provide. Meanwhile, i have every ability to choose the collection type that i want to use, or to modify it later on. Furthermore, i can eliminate the possibility of side-effects in my code due to unexpected externally caused mutations in the state of the collection.

The only situation in which i think it’s OK to return a real collection type is if you have a method which is responsible for creating a list, but is not supposed to hold on to it. In that case, the created collection is clearly intended to be used in whatever way makes sense by the consumer. After all, you created the collection specifically for the consumer so they can do whatever they want with it. But if you need to hold a reference to the collection for some reason, then you probably also have more responsibilities than merely creating the collection. In that case, the collection is yours and you should encapsulate it as such.

There is indeed a legitimate possible problem here: any possible mutation of an instance field in a method can have an intended or unintended impact somewhere else in the class since the mutation will outlive the duration of the method call. So it is important to be aware of this and that you are entirely sure that any possible mutation is actually intended and that no unintended mutations will occur because of some faulty code in a method. I don’t however think that prefixing field names is the best solution to avoid this problem. There are two practices that i recommend to easily avoid unintended mutations of fields in methods.

The first is to use as few fields as possible. To avoid any misunderstandings: i’m not saying that you shouldn’t use fields! I’m just saying that fields need to justify their existence. Fields inherently make up the state of an object, so if you don’t need a particular piece of data to hang around longer than say, the duration of a method call, then don’t put that data in a field. If you need to access that data in another method that will be called from the originally called method you can simply pass it to the other method with a method parameter. If you notice that you’re frequently passing the same pieces of data to a couple of methods, then you probably need to introduce a parameter object. Simply put: do not use fields unless the data you want to store in them are an inherent part of the object and the data needs to hang around for a while.

The second practice is too keep your methods short and focused. If you’re working with large methods, then i can certainly understand why you would want all the help you can get to easily spot mutations of fields. There’s only one question: why are you working with large methods? There are truly very few legitimate reasons for not splitting up large methods into separate reusable methods. When you use many small methods instead of large methods, it’s much easier to keep your focus on what any particular piece of code is supposed to do, and what it’s really doing. And if your methods are short, you will very easily see when a field is being used instead of a local variable.

The combination of these two approaches leads to a lot less unintended mutations of fields. And as a bonus, you get a lot more readable and maintainable code as well. If however you still like to get some visual help in identifying field usage in methods, you can enable the Color Identifiers feature in Resharper (available in the Options window under Code Inspection – Settings – Color identifiers) which will result in fields being represented with a different color from regular variables.

What do you think about this? Do you still prefer to prefix field names, and if so, why?

In the past two years we’ve seen the .NET world gradually accept the concept of TDD, and it has been extended somewhat with the whole BDD thing. However, there hasn’t been a single fundamental change which allows you to take away that inherent flaw. Every single variation that has been introduced in the TDD/BDD world is honestly very minor (dare i even say pointless?) because it all boils down to different syntax and slightly different ways of organizing your test fixtures. But again, even if you are doing the very latest flavor of the month when it comes to automated tests, you’re still not protected from problems that you didn’t think of.

Mark Meyers, a former coworker of mine, has been working hard on porting QuickCheck to .NET and the result is the QuickNet project. Instead of being yet another minor evolutionary step in the automated testing world for .NET, you could actually consider this to be a revolutionary improvement. For the .NET world that is, since other developer communities have adopted this new approach already some time ago.

I highly encourage you to check out what QuickNet is about. I’m about to get much more involved with the project, from a development point of view as well as using it and trying to spread the good word. This is something that actually can offer you substantial benefits over classical unit testing approaches so you really would be doing yourself a huge favor in giving this a shot. Keep in mind that it’s still pretty early and that the codebase is still going through some major changes. There is no official release yet, so breaking changes can (and probably will) occur if you already try it out.

There also isn’t any official documentation yet either, but Mark has some great posts about QuickNet’s usage and there’s also a couple of nice examples in the code already. In fact, we also have a few QuickNet tests to test… well… QuickNet itself. Head on over to some or all of the links i put in this post, and start learning

The problem obviously is that you can’t override the value that DateTime.Now will return during your tests. Many people seem to resort to using some kind of DateTimeService dependency which each piece of code that needs the current date will use. Basically, something like this:

The implementation that will be used at runtime then looks like this:

Code that needs the current date simply declares a dependency on IDateTimeService and at run-time the IOC container will inject an instance of DateTimeService to fulfill the IDateTimeService dependency. At test-time, the IDateTimeService is mocked so you can easily set which date should be returned for each test.

Personally, i’m not a fan of this approach. I mean, i use the same approach for most dependencies but for simply getting the current date this is a bit too much IMO.

Instead, we simply use something like this:

And our real code simply calls DateTimeProvider.Now instead of DateTime.Now. In our tests, we call the SetDateTimeToReturn method to provide the date that we want to use for a particular test. At the end of the test, simply call the ResetCurrentDateTime method and that’s it.

I generally don’t like static methods but in this case, this is a very simple solution to this specific problem. And you know how the saying goes: “do the simplest thing that could possibly work”. And as long as that works, resist the urge to change it.

• We have to be able to easily retrieve what user X changed in the database on day Y or during a certain time frame.
• We need to know what record X looked like at point Y in time, and be able to show a historic list of changes for a specific record.
• We need to configure the duration for which auditing data must be kept in the database on a per-table (or per-schema) level

We’ve done this in the past, but never in a manner that is just perfect (or close enough to being perfect anyway) for both requirements. So we discussed two alternative approaches to tackling this problem.

The first approach is to have 3 tables. The first two tables would contain metadata about the database structure (tables and columns basically). The third table would have a reference to each column with a previous value, the new value, who changed it and a timestamp of when the change occurred. We would use database triggers that would store the appropriate auditing data in the third table for each action (insert/update/delete). The benefits of this approach would be that it would be pretty easy to set up and also easy to query which changes were made by a certain user. It would be a bit more complex to reconstruct the state of a record at a certain point in time, but it would still be doable. The biggest downside (in my opinion), is that for each insert/update you would have X amount of inserts into the auditing table, and you’d also have to either perform some queries to get the identifier values of the relevant tables/columns or hardcode those identifier values in the generated triggers to avoid the cost of the extra select statements. So if you have an entity with 12 columns, an insert into the entity’s table would mean 12 inserts into the auditing table. Updating 4 columns of that entity would lead to 4 insert statements in the auditing table, etc…

The other alternative that we considered was to use a specific auditing table for each real table, and every time a user does an insert/update/delete, insert one record into the table’s specific auditing table with the current state of the record along with a timestamp, the userid, and an indication of which action was performed (insert/update/delete). This insert would also be done with database triggers. The benefits of this approach would be that it would be very easy to show what the state of a certain entity was at a certain point in time, and that you’d only pay the cost of the single extra insert. There are however two big downsides to this approach. The first is that it’ll lead to an explosion of tables. We’d probably store the auditing tables in a separate database but you still basically have twice the amount of tables (and scripts!) that you’d have to worry about compared to what you’d usually have. We can very realistically expect a couple hundred of real tables in a few years, so you’d have to multiply that by two if you’d go for this auditing approach. Another big downside is that it would be very expensive to perform a query which would tell you what user X changed at point Y in time (or during a time frame).

Neither solution appears to be ideal. Also, this database will definitely grow a lot (more tables and obviously data) as we add more functionality and it’s pretty safe to consider this entire project as something that will be expanding in functionality for a couple of years to come.

So my question to you is: Which approach do you think is best, and why? Or better yet, is there a better approach that we simply haven’t thought of yet? I would definitely appreciate some feedback on this (either on the validity of both approaches or alternative approaches) so please do feel free to leave your thoughts in the comments

“are you sure you can cleanly add the hardcoded identifier values in the generated database triggers?”

*shrug* What could possibly go wrong?

1. Career Advice For Young Developers

   This is one of my personal favorites so it was nice to see this one at the top of the list. I really think the first 2 or 3 years of a developer’s career are crucial to the rest of it, so i hope this helped a few people.

2. At This Point, I’d Prefer Java Developers Over .NET Developers

   This one caused a lot of controversy. I’ve interviewed way too many lousy .NET developers in the past couple of years, so naturally i was very impressed when i had much more positive experiences when interviewing a couple of java developers.

3. NHibernate Mapping Examples

   One of my very first posts. It’s sorta outdated because it still uses NHibernate 1.2 and certainly doesn’t cover everything. But i do think it’s still a pretty good reference for people who are getting started with NHibernate.

4. Build Your Own Data Access Layer Series

   This series was very successful and was a lot of fun for me to write as well. Some of the individual posts got better stats than some of the other posts in this list, but since they’re all part of the same series i only included this one. And every addition i’ll have to make to the data layer discussed in that series will be turned into a new post

5. Upgrading To NHibernate 2.1

   This is so typical… when we released NHibernate 2.1, we introduced a new required configuration setting. If you don’t have the required configuration setting, NHibernate throws a very detailed exception telling you what to do to fix the problem. Instead of reading the exception message and fixing the problem, most people just seem to copy/paste the exception message into their favorite search engine, click on the first link they see and then read what the blog post says instead of just reading the exception message. Unbelievable.

6. Data Access With NHibernate

   Just my implementation of a Repository base class to be used with NHibernate. I guess it got a lot of views just because it showed most of the basic things everybody will be doing with NHibernate, and should be doing with any other data layer for that matter.

7. Sending NHibernate entities over the WCF wire

   This is a post that i definitely regret writing. I am now totally against the concept of distributing entities, but when i wrote that post i didn’t think it was that horrible so i documented how to get it working. Luckily, i never actually used this in a real production system.

8. Recommended Books

   This is a page on my site instead of a post… but it’s gotten so many views that i guess it deserves to be in this list.

9. Managing your NHibernate Sessions

   My Unit Of Work implementation which sort of abstracts the NHibernate session, but still makes it fully available in Repository classes. Still using this quite happily in all of our applications

10. Tired Of Working With Big Visual Studio Solutions?

    We all know what a pain Visual Studio is with large solutions, right? This trick at least reduces the pain.

11. Genesis: Bridging The Gap Between Requirements And Code

    If you don’t know what this is about, then you definitely need to check it out!

12. Must Everything Be Virtual With NHibernate?

    I recently revisited this topic with a detailed example, but this post is the theoretical explanation of why NHibernate wants you to use virtual properties and methods in your entity classes.

13. The Request/Response Service Layer

    I got the idea from this from one of Ayende’s posts, so i can’t take credit for that. But i am very proud of the implementation and it is still working extremely well for us. I really can’t imagine going back to typical WCF services after having used this approach so successfully for over a year now. I’m actually thinking about writing an extensive series of posts on this. If you’d be interested in such a series, be sure to let me know… it might convince me to start writing it sooner rather than later

14. How To Write Testable ASP.NET WebForms

    The MVP approach we use whenever we use WebForms. Which is… well, hardly ever anymore (except for one never-ending project). Silverlight FTW!

15. Educate Developers Instead Of Protecting Them

    My rant against the typical “we need to protect developers from theirselves”-approach that i see too often in this industry.

16. What It Takes To Be A Great Technical Lead

    Once again, i don’t claim to live up to that i wrote in that post but i do think those are the qualities that a great technical lead has to have.

17. The Good, The Bad And The Ugly In The .NET World

    Some thoughts on why i think the .NET world isn’t as good as it could be.

18. Why On Earth Would A Developer Do This?

    My reaction to reading a piece of example code in a book from one of the guru’s we all love and respect.

19. Slutty Types

    This one made it up here pretty fast. I can only hope the name sticks and that i have at least introduced ONE thing to the world of software development

20. Populating Entities From Stored Procedures With NHibernate

    Sometimes, it actually makes sense to use a stored procedure here or there… so you might as well know how to get that output into an entity instance easily.

Well, not necessarily. You can very easily write bad tests which execute most, or even all of your production code, while the tests themselves probably don’t cover everything that really needs to be covered. Even if you’re a disciplined developer who is very careful not to make mistakes, the odds that your code will contain bugs that your tests didn’t catch are still relatively likely. For those of you who write automated tests (either test-first or test-after): how often has it happened to you that a bug was discovered later on for some edge case that you didn’t think of when writing the production code or the test code? No matter how good you are, this has happened to you on more than one occasion. And it will happen again in the future.

Here’s the important question though: how frequently does it happen that bugs are discovered in pieces of code which have high coverage during the test-runs? It might not happen every day, it might not happen every week but it definitely happens occasionally and in some cases even frequently. What exactly does that tell you about the value of a metric such as code coverage? You might think that if this situation comes up, you don’t have proper tests in place but that’s not necessarily the case. You can have an incredibly good test fixture (or several) for a certain piece of code but if you and/or your teammates didn’t happen to think of a certain edge-case or even something that might be obvious, then you didn’t write tests for that. Even though the build report might indicate 100% coverage for that piece of code.

I’ve always thought that code coverage is only meaningful when it’s low. Low code coverage can at least definitively tell you that certain parts of code are never executed during test-runs and are thus completely untested. However, it will never definitively tell you which parts of code (or how much of it) are guaranteed to be covered correctly by your tests. As such, i would say that code coverage can only be used as an indication that something is wrong, but never as an indication that something is good/right/correct/great.

I know i wrapped up the series already, but i just had to add the ability to do bulk inserts to this data layer so i figured i’d might as well post about it. Ayende already talked about how to enable the ability to batch inserts (or updates and deletes) here and here so i’m going to skip that part. I used the exact same trick and created a PublicSqlCommandSet class which wraps the hidden SqlCommandSet class. Again, if you have no idea what i’m talking about in that last sentence then you need to read Ayende’s 2 posts that i just linked to

After that, adding the bulk insert feature to the DAL was as simple as creating this class:

And then adding this to the Session class:

Obviously, the method signature was also added to the ISession interface. The batch-size and commandtimeout parameters are currently hardcoded but they should come from some kind of configuration file.

All in all, pretty easy stuff

• give you access to their privates without too many difficulties
• don’t really care about your intentions, or if they do, aren’t very clear on that
• occasionally seem like a good short-term fix
• can be used in a variety of ways, with different outcomes and none of them are guaranteed
• can not to be trusted
• really need to be tested
• will burn you sooner or later if you’re not careful
• become even more of a mess during the aging process

Feel free to add to the list

But these views do have to interact with each other. I didn’t want to use typical events because that would require either a certain view to know about another view to be able to subscribe to its events, or you’d need some other component which knows which views need to be hooked to each other. We really need maximum flexibility for what we have in mind with our views, so it only made sense to finally start using the Event Aggregation pattern. The idea is that a view can basically publish events, without knowing who is subscribed to these events, and that suscribers will be notified whenever these events occur. However, subscribers don’t know anything about who is publishing the events. Instead, both publishers and subscribers only know of the Event Aggregator. A publisher tells the aggregator to publish an event to all subscribed listeners for that event. Each subscribers simply tells the aggregator “i’d like to be notified whenever this event occurs, and i don’t care where it comes from”.
Plenty of implementations of this pattern can be found online already, so i figured: why not add my own? :p

Fist of all, an event is nothing more than a class that inherits from this class:

Every event should inherit from this class, and add whatever necessary properties that are important for that particular type of event.

If a class is interested in listening to a specific event, it needs to implement the following interface:

If a class is interested in multiple events, it simply needs to implement the generic IListener interface for each type of event that it wants to handle.

Then we obviously need the Event Aggregator. I wanted an aggregator that allowed listeners to either subscribe/unsubscribe to/from very specific events, or just subscribe/unsubscribe to/from whatever it supports. So i have the following IEventAggregator interface:

The Subscribe and Unsubscribe methods that simply take an IListener reference will either subscribe or unsubscribe the given listener to/from every event that it can handle. In other words, for every generic IListener interface that it implements. Yet you also have the ability to subscribe/unsubscribe from a specific event type.

And here’s the implementation:

In case you’re wondering… the IDispatcher interface is merely a way to wrap Silverlight’s real Dispatcher. We wrap it so we can use a different implementation of the IDispatcher in our automated tests. Other than that, the implementation is very straightforward.

We started using this very recently, so this implementation might change in the upcoming weeks, but for now it does what it needs to do and it does so pretty well. In our case, every view’s Presenter automatically has an IEventAggregator property so whenever we need to publish an event, we can simply do something like EventAggregator.Publish(new SomeEvent(someParameter)). Or, Presenters that need to listen to events can simply say EventAggregator.Subscribe(this) or only subscribe to some specific events whenever they need to and their specific Handle method will be called whenever someone publishes the event. This also allowed us to get rid of the somewhat awkward syntax when testing events (subscription, unsubscription and the actual handing of events) with mocking frameworks.

And as a last bonus, i put a call to the Unsubscribe(IListener) method in the Dispose method of our base Presenter implementation. Which means that none of them will be left subscribed to events by accident anymore

I’ve always thought that Intellectual Honesty is a very important trait that every developer needs to have. I also believe that it is too frequently missing in this business. Some people just want (or need) to be right all the time, even if they are wrong. In software development, it’s generally in everyone’s best interest to go with the best possible solution to a given problem, while still keeping all relevant constraints in account. Some developers have a genuine interest in the architecture that is used and how things should be done. That is obviously a good thing and i wish there were more developers like that.

I’m in a position where i have a lot of influence on architectural decisions and how we should develop our code. But i’ve never wanted to be the only one who had to make these decisions, nor do i want people to just go ahead with every idea that i have. I want people to get involved with these things. I want feedback. I want to hear ideas from other people that are better than my own. It’s better for everyone if multiple people are involved in such discussions and decisions. Get a couple of people together, discuss things, go over the options and eventually pick the best proposed solution no matter who came up with it. That’s always been my approach and it always will be. And i truly believe that it’s a healthy approach for everyone involved.

But there are always people who either want to be the only one who gets to decide these things, without input from others, or are generally unhappy in their job if they believe their ideas aren’t being considered.

My question to these people is: why? Why does it matter if another person’s solution is chosen? Why would you need to be frustrated or disgruntled if your solution wasn’t chosen? If you’re working for a company where your ideas aren’t even considered then sure, you have every right to be frustrated or disgruntled (and i should know, because i’ve worked in such a place in the past). But if you’re working for a company where you know full well that everyone’s ideas are considered, then you really have no reason at all to complain if your solution wasn’t accepted.

Unless of course, you are more concerned about your personal ambitions instead of the actual results. If all you care about is your status, position or whatever you want to call it, then you really are in the wrong business. Sure, there are companies where you can make quite a career out of such an approach, but it’s just not healthy. Not for you personally, nor for your employer, nor for your customers. It doesn’t help anyone but yourself, and that sure as hell won’t last forever.

Be honest, at least to yourself and preferably to the people you work with as well. If your ideas don’t make it, then you might need to question your approach (and for some people specifically: your tactics), your real motivations, or perhaps even your skill level. Again: be honest about what you can do, what you can’t do, what you know and what you don’t know. And learn how to work with other people, instead of simply trying to get ahead of them.

I’d like to end this post with a quote from Dale Carnegie:

Any fool can defend his or her mistakes, and most fools do.

NHibernate allows a private default constructor for Value Objects, but for Entities you will need a default public or protected constructor as private is not sufficient.

I got the following comment from someone:

I too am trying to determine how well NHibernate lives up to the promise of persistence ignorance. I can definitely live with unnecessary private constructors, but I’m dubious about adding protected constructors just to support an ORM.

At any rate, I was surprised by the sentence I quoted, because I didn’t realize there were any circumstances in which NHibernate required protected default constructors.

Once again, the answer is related to the dynamic proxies that NHibernate uses. Value Objects will never be proxied by NHibernate, so NHibernate only needs a private default constructor to create the instances. If an entity is eligible for lazy loading however, then NHibernate will create a type which inherits from your entity (this is described in depth here and here). Which means that we really need either a public or protected constructor in entity classes that are eligible for lazy loading. Consider the following class:

If we try to create the following derived class:

We get the following compiler error:

Error 1 ‘ConsoleApplication1.SomeEntity.SomeEntity()’ is inaccessible due to its protection level

It’s a silly example, but it does show why entity types need at least a public or a protected default constructor and why a private one isn’t sufficient.