How come that companies hire recruiters to find new developer employees for them? Apparently it’s either hard to find them, or they do not want to make the effort to find them their selves. If it’s the latter, it could be because the company is really, really small and they don’t have the resources. But in all other cases, maybe developers should start wondering if they want to work for such a company.
But let’s get back to the first reason; let’s assume it’s hard to find new developers.
Simply for this reason, employers are willing to pay immense amounts of money to recruiters, sometimes tens of thousands of dollars. But when you ask them how often their developers go to conferences, most of the time the answer is that every year only a few can go to the Microsoft TechDays.
Some companies have 5 developers at work and send all of them to the Microsoft TechDays. How can a company with 100 developers employed, tell me without being ashamed that they only send 5 developers to the Microsoft TechDays. When asked, I was told that sending many developers costs a lot of money. But is it so wrong of me, to question their intention? Because if they have 20 times more developers, aren’t they making at least 20 times the money? So it’s obvious that TechDays will costs 20 times as much as well. In other words, it’s all relative and in the end, the company isn’t making more costs than the company with 5 developer employees.
Of course I understand you cannot simply send 100% of your development department to a conference, all at the same time. Your customers will probably not accept that.
Invest in your employees
But what I cannot understand is that you’re willing to pay an insane amount of money to a recruiter, but you’re not willing to invest in your employees! What about the idea to send 50% of your developers to the Microsoft TechEd Europe every other year? That way every single developer will visit TechEd every other year, but there’s always 50% of your developers working at your customers. What do you think the result will be?
I know not every developer is like me, but I’d expect every great developer lining up at your doorstep, applying for a job at your company. Especially since you’re probably the first in The Netherlands to support your employees like that. You don’t need recruiters anymore and you can invest the money saved in your own employees.
Want to know why Microsoft and Google have the best developers in the world? Because they provide their developers the best benefits that go around. Free lunch, great hardware, conferences and Google even has slides that end up in the restaurant. Today I read that every seat at the Google office is at most 150 feet of a restaurant or another place where their employees can get something to eat. Simply because that’s where the best discussions are being held and the best ideas are being produced.
Create an atmosphere people feel happy in, it’ll make them more productive
When you invest in your employees, it’s not only for them gaining knowledge. It’s also creating an atmosphere where people love to work. This will not cost you much, especially when you consider what it’ll cost to replace someone with the knowledge a developer has. Besides technical knowledge, they also have all the knowledge of the current system and especially of the business domain you’re working in. I once read that a very thorough research was done and that creative employees like developers cost around $50.000 to replace, taking everything into account. You can seriously cut down on costs by investing in your employees!
Again, try to provide a great place to work at. Provide them with great hardware, some gadgets like a Surface RT/Pro tablet, etc. Free lunch works really, really great. And provide them the chance to go to a conference at the very least every other year! Contact me if you’re willing to make me an offer! And I’m not kidding!
Additional information
For Dutch readers, here's another post on Facebook about recruiters. If you really need to hire a recruitment agency, I have a recommendation there as well... :-)
For SDN Event of June 14th I did two presentations
Transactions
Why are transactions the bottleneck of so many applications? Why isn't the database always consistent, even though we use transactions? This session explains why everything in a database is a transaction and how a developer should deal with them. Why your software complains that MSDTC isn't running and how the CAP Theorem can help. After this session you'll be able to explain to your DBA why he doesn't understand transactions.
Slidedeck here
I spoke about messaging, of which you can find more information here - What is messaging
- High Availability (a good article on benefits of messaging)
SOLID Principles part 2
Of the SOLID principles, made famous by Robert C. Martin, we'll discuss the Interface Segregation Principle and the Dependency Inversion Principle. This session will explain them thoroughly and give real life examples instead of the regular customer & order examples. You'll walk away knowing what the benefits are and how to use them properly.
Slidedeck here
Demo code
During the presentation the implementation of the Factory was incorrect, as the objects instantiated weren’t done so using the Unity Container. This is fixed in this demo. The EmailMessageSender even uses an additional IResourceRepository to retrieve (faked) translations from the database.
If you have questions, don’t hesitate to contact me.
It’s kind of sudden, but we are moving BloggingAbout.NET to a new datacenter. I’m behind my desk now, but getting ready go move it right now.
Hope you get this message before it’s down! ;-)
Update
We were migrated to the new datacenter without any loss or problems. The only problem might be logging in to the website. If you experience problems with it, remove all cookies related to BloggingAbout.NET and you should be fine.
We’ve all seen the comparison between development work and constructing buildings. I think the comparison is fundamentally flawed. There are numerous posts out in the world that confirm this. Random Google articles are here, here and here. I like the last one on Stackoverflow, because the writer is quite cynical when answering the question why they differ.
They [customers] can't take delivery of your finished underground carpark and ask you to add an airport (also underground). - They aren't allowed to change the law of gravity after you finish the design. Or expect the building to work on another planet.
- They don't blame the architect when they can't get an 18 wheeler delivery truck through reception, into the elevator and to the loading dock that they demanded be on the 24th floor.
The reason I write this post however, is because I found another analogy. In my family there are a lot of people actually working in construction. I benefit greatly from it, because it’s one of those areas I severely lack the skills in. However at some point in time, a family member was working in his own house and needed to replace some electrical wires. I did some of this in my own house and was asked to help out. I was quite happy with that, because now I could return the favor of him helping me out all the time.
And when wiring up all those wires, it suddenly dawned to me. This is like developing software. Connecting these wires is just about coupling and making the right decisions on what goes where. And that’s what I do all day. Coupling lines of code, methods, classes, components, services, etc, etc. The reason I think I’m better at it than my family member is because I’m good in seeing the bigger picture, the helicopter view if you will, of everything that is connecting to one another. I know which parts to focus on and which parts I don’t need immediate details of.
However in software development, there are many times more connections. Probably comparable to a network of electrical wires through an entire football stadium. The system I’m currently working on is becoming so large and complex, that after about 6 years of development –in comparison- it could spawn an entire city of electrical wires. Just imagine the complexity for a small group of developers this can bring.
Another important difference with the regular electrical wires, is that software development is a very creative process. Although you (can) have a plan, an architecture, design and great developers, it’s not constructing a new building with the patterns and ways you used to build the previous building with. It’s more or less like how a painter, a real artist, would create a painting. Like Rembrand or Van Gogh would paint a painting. Unfortunately there are also a lot of developers that don’t come near the skills that a proper painter has, which can even be a recipe for disaster. One of the reasons why projects go over time and budget so often. But that’s something for another blogpost.
I recently spoke with another company and they were pretty proud about the fact that they had sent 5 developers to the Microsoft TechDays. Of about 100 developers they only sent 5! Claiming that sending everyone is too expensive. If a company of 5 can send 5, which is 100%, why can this company only send 5% of their employees? I wrote this blog post because I have the feeling a lot of employers do not appreciate the creativity of their ‘artist’ employees. They do not understand the complexity and challenges that come with the territory that is software development. I think a company like Google does understand. Every office that houses their software developers, contain great perks like free lunch, sleeping pods, slides into the cantina, thinking rooms with only the light of aquaria, etc, etc. That is why they have some of the best developers in the world!
So besides explaining my analogy, this post is to make employers understand how valuable their software developers are. Good developers spend a large amount of private time (at home) to improve their skills. This reflects immediately back on their skills at work. Return the favor by showing you appreciate them. Return the favor and investing in them as well.
Thank you.
For March 18th I did two presentations
Data replication or data duplication
As systems are growing bigger and more complex, we are looking for different ways to work with data. An example of this is CQRS and Event Sourcing which take a different approach over standard CRUD based systems. But when the authorities on CQRS tell you that it's not a top level architecture, what do they actually mean? How should the system than be divided? In this session you'll learn the differences and why you should be replicating data, but not duplicating data.
Slidedeck here
I will try to upload the demo code at some point when it’s done.
SOLID Principles part 1
Of the SOLID principles, made famous by Robert C. Martin, we'll discuss the Single Responsibility Principle and the Open/Closed Principle, two of the presenter's favorite principles. But at the same time the least understood and used principles. That's why this session will explain them thoroughly and give real life examples instead of the regular customer & order examples. You'll walk away knowing what the benefits are and how to use them properly.
Slidedeck here
I will upload the demo code later
I spoke about the Template Method Pattern as well. More information on my blog at the following locations - Template Method Explanation
- Template Method Example
- Template Method Advanced Example
If you have questions, don’t hesitate to contact me.
At work we’ve been using Enterprise Library for quite some time. A new colleague came in a few months ago and he’s apparently in love with log4net. And I’ve been proving over and over again that Enterprise Library logging can do what log4net can do. It’s probably that patterns & practices don’t have a budget for MVP titles, or I’d already have a few! ;-) But kidding aside, again some EntLib logging was replaced with log4net because of color coding to the console window. I thought this was indeed quite handy so I decided to write my own custom TraceListener.
For your personal pleasure I’ve immediately created a NuGet package and this is the tutorial on how to use this logger for yourself. The tutorial is very, very detailed. That’s because apparently that’s how a lot of people want it. In other words, those are the posts that get the most views and comments! But it’s really simple to get this going.
- Install-Package Common.Logging
- Install-Package Common.Logging.EntLib50
- Install-Package EnterpriseLibrary.Logging -Version 5.0.505.1
- Install-Package ColoredConsoleTraceListener
- Configure Common.Logging as described in the first steps.
- Configure Enterprise Library logging with my custom colored console trace listener
- Done
You can find the NuGet packages for the Colored Console Trace Listener here:
Enterprise Library Colored Console TraceListener
- I’m using Visual Studio 2012 but this is equally simpel in Visual Studio 2008. It uses .NET Framework 4.0 and I haven’t tested it in any other environment. If there’s a need, let me know and I’ll see what I can do.
- The tutorial creates a new console application, but you can add this to anything you’d like.
- I love Common.Logging and I’ve added color coding based on TraceEventType that the Common.Logging provides to Enterprise Library. If you’re not using it yet, you might start doing so. It’s really easy to program against and swapping out one logging framework for another is a breeze as well.
Add Common.Logging
In this part we’ll create a new project and will add Common.Logging to the project. If you don’t want to use Common.Logging you can skip this step entirely.
- After you’ve started Visual Studio, create a new Console Application called ConsoleApplication1.
- If you haven’t got the Package Manager Console available yet, do so via View –> Other Windows –> Package Manager Console.
- Open the Package Manager Console and execute the following commands
- Install-Package Common.Logging
These the regular Common.Logging classes - Install-Package Common.Logging.EntLib50
This is the factory-adapter specifically for Enterprise Library 5.0
- Now edit your app.config so it looks like the following
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="common">
<section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<common>
<logging>
<factoryAdapter type="Common.Logging.EntLib.EntLibLoggerFactoryAdapter, Common.Logging.EntLib50" />
</logging>
</common>
</configuration>
What we see here is the config section for Common.Logging defined and the section itself at the bottom. Here you can see the factory-adapter to EntLib 5.0. Every single logging framework needs its own factory-adapter. EntLib has several because of the different versions. You can also add log4net, Elmah, etc, etc. However you can only add one at the time.
Add Enterprise Library logging
In this part we’ll actually added Enterprise Library logging. If you’ve already get Enterprise Library logging set up and running, you can skip this part.
- Open the Package Manager Console and execute the following command
- Install-Package EnterpriseLibrary.Logging -Version 5.0.505.1
This will add quite some references, amongst others to Enterprise Library common libraries, Unity and the CommonServiceLocator.
- In Visual Studio select Tools –> Extension and Updates. A windows will pop up.
- Select “Online” in the left pane.
- Search for “EntLib Config” and install the “EnterpriseLibrary.Config” package.
- This helps configure Enterprise Library, because all the XML for these logging frameworks can be quite hard to learn.
- After installation, you need to restart Visual Studio
- Right-click the App.config file and select “Edit configuration file”
- Select “Blocks” from the menu and select “Add logging settings”
- Click the 4 blocks in the most left column
“General” is a category. Everything you want to log with default Enterprise Library, without specifying a category, will automatically log under this category. After clicking it, you can see that it is linked to the “Event Log Listener”, which logs all information to the EventLog. Because we won’t be using this, we’ll remove the link. Click the little arrow in the left corner and the window will expand. You can see the “Event Log Listener”, click the cross behind it so it’ll be removed. You can see this in the image on the right. - “All Events” is a catch-it-all.
- “Unprocessed Category” is where everything that does not have its own category will go through. We will use this to output the logging information to console and to a file. When appropriate, we’ll log to a specific category, but we’ll get back to that in a next blogpost.
- “Logging Errors & Warnings” is for when Enterprise Library itself crashes. This is useful for debugging purposes, but you have to be absolutely sure that this will be able to log. It’s useless to put an EventLog listener under here, if you’re not 100% sure you are authorized to log to the eventlog. As you can see this is configured by default however.
- We have now clicked all four items, but let’s have a look at default logging configuration. Click the double-arrow down to the right of “Logging Settings” and more information will open up.
- “Default logging category” has the category “General”. As said, this is where message will go to when no category is defined.
- “Warn if no category match” should be turned off. We will heavily be making use of this feature.
We’ll now add a trace listener to the “Unprocessed Category” so that our messages will be logged to file.
- In the second pane called “Logging Target Listeners” click the plus sign.
- Select “Add Logging Target Listeners”
- Select “Add Rolling Flat File Trace Listener”
- A new trace listener will appear. Let’s fill in the details
- Name : Rolling Flat File Trace Listener
- File Name : d:\logging\consoleapp1\trace.log
This can of course be anything you want, just make sure the tool can log here.
- Formatter : Text Formatter
- Roll Interval : Day
Every day, a new file will be created
- Now that we’ve added a new trace listener, let’s attach this to our “Unprocessed Category” items.
- Click “Unprocessed Category” again
- Click the plus sign
- Select the “Rolling Flat File Trace Listener” we just configured.
Now we’re done with that, let’s look in Visual Studio again what changed and what will happen if we start logging.
- Save the current configuration. No errors should be at the bottom of the configuration tool.
- Go back to Visual Studio to check out the App.config and what was made of it. Make sure the Common.Logging settings we added before are still in there.
- Go to the only class in your project called “Program”
- Make it look like the code below. Do not forget to add the using statements for all classes and interfaces used.
using Common.Logging;
using System;
using System.Collections.Generic;
using System.Linq;
namespace ConsoleApplication1
{
class Program
{
static readonly ILog Log = LogManager.GetCurrentClassLogger();
static void Main(string[] args)
{
Log.Debug("Debug");
Log.Info("Info");
Log.Warn("Warn");
Log.Error("Error");
Log.Fatal("Fatal");
}
}
}
What we did was initialize the logger in the readonly ‘log’ member variable. We ask for the CurrentClassLogger. We’ll get back to this in another blogpost about Common.Logging and Enterprise Library. Next we log a message for every loglevel, according to Common.Logging.
When you execute the code, at the given location (d:\logging\consoleapp1) there should be our log-file. The content is quite verbose, but after the keyword “message”, is where our message should be provided. With our colored console tracelistener we’ll make this more visible in the console window.
Add Colored Console TraceListener
As said I’ve already created NuGet package for the Colored Console TraceListener. Let’s add that to our solution, configure it and look at what the code we currently have does.
- In the “Package Manager Console” execute the following command
- Install-Package ColoredConsoleTraceListener
- Compile the solution with CTRL+SHIFT+B so that the referenced tracelistener will be in the debug folder.
- If you haven’t closed the Enterprise Library configuration than ALT+TAB to that again.
If you have closed it, right-click App.config again and select “Edit configuration file” again
- Add the plus sign next to “Logging Target Listeners” again to add an additional trace listener.
- Select “Add logging trace listeners”
- Select “Add custom trace listener”
- In the window that just popped up, press the “Add from file” button.
- Browse to the folder where your ConsoleApplication1 is located and find the “packages” folder, where NuGet stores its packages.
Is should be located around here : packages\ColoredConsoleTraceListener.1.0.1\lib\net40\EnterpriseLibrary.ConsoleTraceListener.dll
- Select the EnterpriseLibrary.ConsoleTraceListener.dll file
The original window that popped up should now contain a tree where you can select the “ConsoleTraceListener” as shown in the image on the right. - The only thing we need to configure is the formatter. We’ll create a new one because the current one is much too verbose.
- In the right pane, click the plus sign next to “Log Message Formatters”
- Select “Add Log Message Formatters”
- Select “Add Text Formatter”
- In the new formatter, set the properties as follows
- Name : SingleLineText
- Template : {win32ThreadId} - {timestamp} : {message}
This contains a timestamp and the ThreadId so you’ll know which messages belong together in a multi-threaded application.
- Back to our ConsoleTraceListener where you should specify the Formatter to “SingleLineText”, which we just specified.
- Back to our “Unprocessed Category” block in the left pane. Add another trace listener via the plus sign and select the “ConsoleTraceListener”
- Save the configuration
- Go back to Visual Studio 2012
- Press CTRL+F5
Now without changing a single line of code, the console window should look as follows. This is what we configured via our Colored Console TraceListener. At the far bottom the final EntLib Config tool.
Update : Updated for Enterprise Library 5, since 6.0 came out
We probably all learned this at school. When you build software, you analyze requirements, find the nouns and build an entity-relationship model, an ERD. You start with the first normal form and normalize the model until you start building software upon it. But when you’re building software in a distributed environment, multiple components will likely need to access the same data. In the most traditional of systems, you’ll have a single database with great value in it, because all data the is valuable to your company is in this database. And all those components are based on this data, so they need access to it. Being more concrete, you can think of this as multiple Visual Studio solutions with projects and they all have connection strings to this high value database.
We all know coupling is bad, however we don’t always know how to fix this. Because we don’t know where the worst coupling is. Let’s think about this for a minute. We build layers into our software, sometimes even separated through additional facades implemented through SOAP and XML. And than we tell ourselves the user interface is decoupled from the database. So that changes in the database can be made without affecting the upper layers and the user interface. We’ve hidden this behind a data-layer and use complex O/RM solutions to hide even more behind models with complex mappings to the database. Until even the slightest change means updating the model, the mapping, the data-layer and even business logic, facades and everything all the way up to the user interface. Even worse, this change, which took too long to build… it completely breaks other components in our distributed architecture.
I’ve seen so many solutions trying to fix this. From stored procedures that can be changed on the fly (but without proper testing), to additional tools that should fix problems, to ad hoc data changes. And I just deliberately mentioned the three worst solutions, in my humble opinion. Because too many people execute these so called fixes, ranging from junior developers on the maintenance team to the senior DBA. The problem is, that all of them do this without proper knowledge of the business rules. Because these are actually in the code. So how come we still think we can solve all problems using the mentioned solutions?
So coming back to our question, where the worst coupling is. It’s in the database! There’s so much hidden business logic in our data. Some of the data belongs together without anyone being able to notice this. One of the worst invisible coupling I’ve ever seen is where the status of a client was made up out of multiple records in a single table. The state of a client was reflected by a record and second record. Unless there was a third record with some information, than the client had another state. Unless the second record had its timestamp in the past, than it was in even another state. And this went on and on. In the end this resulted in hundreds of locations where all these conditions were checked. These states were however completely invisible in the database! One had to just know what they could possible represent. Until some developer came along and made up another combination of records to present another state.
So how can this be solved? That’s difficult to answer. But a good way to start is try to divide and conquer. Everything that can be taken out of the big database, should be put in another database. That will make the problem smaller and more manageable. Of course it’s ridiculous to just add more connection strings to every single component, so that they can still access the same database. We’d still have the same coupling, but with added complexity of querying the databases. We can’t directly join tables anymore, and don’t get me started on SQL Server’s linked servers.
Will SOAP and XML free us from the coupling? Not really. Or better yet, not at all. Not in the way most people intended to get rid of coupling. Coupling isn’t solved by taking out design time coupling. It’s the runtime coupling that’s difficult to solve. What if the webservice that queries your smaller database is offline, or it’s blocked by requests from other webservices. Or it’s simply not fast enough for your performance demands.
The solution is to decouple these services even during runtime. This means they can’t call each other anymore. We have to make sure they know the answer, before these services are asking the question. How this can be achieved, is something for another post.
I’ve just came back from a trip to Washington DC, where I’ve been at the 50th IAM International Moving Annual Meeting. This was for my employer TellUs, who’s into lead generation for international removal companies. A lot of people asked for the reason why I went to the states, this is it. And of course because we bought a Microsoft PixelSense table which we used to visualize our data on.
The table had to ship however a little before we could finish the applications. After installing them at the convention, everything worked flawlessly. Well, until our sales representatives started working with it. We build a map with thousands of clustered pushpins on it. But there was a problem.
- The push pins did not rotate when sales reps rotated the map!!!
For some reason we did not test rotation of the map on our desktop monitors. Go figure! ;-)
This blogpost is how I solved this issue.
Creating the map and adding pushpins
At the convention, we loaded data and placed push pins on the map. For this tutorial we’ll add them via the double-click event of your mouse. Rotation of the map will occur via clicking on the push pins. The push pins will rotate themselves according to rotation of the map. This tutorial was writing in Visual Studio 2010, because Visual Studio 2012 doesn’t support development for PixelSense (yet). If you are completely unfamiliar with adding push pins to a WPF Bing map, check out this tutorial on MSDN.
First, create a new project by pressing CTRL+SHIFT+N and select “WPF Application” under the “Windows” category. You should end up with an almost empty XAML file with a grid in it. Let’s first add the map to it. First add a reference to the Bing assembly that has all the controls. It should be located in one of the following folders
- C:\Program Files\Bing Maps WPF Control\V1\Libraries\Microsoft.Maps.MapControl.WPF.dll
- C:\Program Files (x86)\Bing Maps WPF Control\V1\Libraries\Microsoft.Maps.MapControl.WPF.dll
After having added the reference, add the namespace to the MainWindow.xaml and add the map. You should end up with the following code.
<Window x:Class="WpfApplication2.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:m="clr-namespace:Microsoft.Maps.MapControl.WPF;assembly=Microsoft.Maps.MapControl.WPF"
Title="MainWindow" Height="350" Width="525">
<Grid>
<m:Map x:Name="myMap" CredentialsProvider="PutYourOwnKeyHere-ItShouldBeVeryLong" />
</Grid>
</Window>
The CredentialsProvider should have a key that you’ve requested on this page or follow the short tutorial on this page. After adding the key you can already run the application and be able to zoom and pan the map.
Adding PushPins from code
As you can see in the above code, I’ve already given my map a name via x:Name attribute. This way I can access my map from code-behind. This way I can set up my code for the double-click event on the map so I can add a PushPin on every double-click by the user. We’ll quickly run through the code, which shouldn’t be very complex.
public partial class MainWindow : Window
{
int counter = 0;
public MainWindow()
{
InitializeComponent();
myMap.MouseDoubleClick += new MouseButtonEventHandler(myMap_MouseDoubleClick);
}
private void myMap_MouseDoubleClick(object sender, MouseButtonEventArgs e)
{
e.Handled = true;
Point mousePosition = e.GetPosition(this);
Location pinLocation = myMap.ViewportPointToLocation(mousePosition);
Pushpin pin = new Pushpin();
pin.Location = pinLocation;
pin.Content = counter += 10;
pin.MouseDown += new MouseButtonEventHandler(pin_MouseDown);
myMap.Children.Add(pin);
}
private void pin_MouseDown(object sender, MouseButtonEventArgs e)
{
}
}
On line 3 you see a counter variable, which we’ll use to add unique push pins to our map. In the constructor MainWindow() you can see that we set up the handler for the double-click event. This is standard .NET code. In the myMap_MouseDoubleClick event handler, we first set e.Handled to true. Otherwise the map control will try to handle the click itself as well, making it zoom-in every time we add a push pin.
In the next two lines we try to retrieve the exact location where we clicked. This can all be viewed in the MSDN documentation and is standard behavior. Then we instantiate a new Pushpin object, give it the location we just ‘calculated’ and add the value of the counter variable to it as content. As you can see we’ve also already set up the event handler for when we press the pushpin itself.
At line 24 we add the Pushpin to the map so that it will be shown. You can now run this application and start double clicking on the map yourself.
Rotating the map & Pushpins
We will now rotate the map as a reaction of the Pushpin that is being clicked by the user. Edit the event handler for the Pushpin click as follows
private void pin_MouseDown(object sender, MouseButtonEventArgs e)
{
e.Handled = true;
var pushPinContent = 0;
var pushPin = sender as Pushpin;
if (pushPin != null && pushPin.GetType() == typeof(Pushpin))
pushPinContent = Convert.ToInt32(pushPin.Content);
myMap.Heading = (double)pushPinContent;
}
As you can see we set the event as being handled again at line 3. The sender of the event should be a Pushpin, so we verify this first and then try to obtain the value of the content of the pin itself. After that, we set the heading of the map, which is the rotation. If you now run the application and start clicking the Pushpins (after adding a few), the map should rotate, but the Pushpins should not.
We can easily fix this by binding the heading property of the Pushpin itself, to the heading of the map control. This can be done by the following code, which should be placed directly before we add the Pushpin to the map control.
Binding binding = new Binding();
binding.Source = myMap;
binding.Path = new PropertyPath("Heading");
binding.Mode = BindingMode.OneWay;
pin.SetBinding(Pushpin.HeadingProperty, binding);
myMap.Children.Add(pin);
Customizing the Pushpin
We will now start customizing the Pushpin to make it show completely different from the default Pushpins. For this we need to create a ControlTemplate in the xaml file. First add a section for static resources in the root object, the Window. Then add the template for the Pushpin. In your existing xaml file, just place the following code directly before the <grid> element.
<Window.Resources>
<ControlTemplate x:Key="CutomPushpinTemplate" TargetType="m:Pushpin">
<Grid x:Name="ContentGrid" HorizontalAlignment="Center" VerticalAlignment="Center">
<StackPanel>
<Grid Margin="0" Width="33" Height="33">
<Rectangle HorizontalAlignment="Left" Margin="-0.208,13.238,0,-0.146" Width="10.555" Fill="#FF005167" RenderTransformOrigin="0.5,0.5">
<Rectangle.RenderTransform>
<TransformGroup>
<ScaleTransform/>
<SkewTransform AngleX="-23"/>
<RotateTransform Angle="-12.944"/>
<TranslateTransform/>
</TransformGroup>
</Rectangle.RenderTransform>
</Rectangle>
<Rectangle Fill="White" Stroke="#FF005167" RadiusX="5" RadiusY="5"/>
<ContentPresenter HorizontalAlignment="Center"
VerticalAlignment="Center"
Content="{TemplateBinding Content}"
ContentTemplate="{TemplateBinding ContentTemplate}"
Margin="0" TextBlock.FontFamily="Segoe UI" TextBlock.FontWeight="Bold" TextBlock.Foreground="#FFB8D30B">
</ContentPresenter>
</Grid>
</StackPanel>
</Grid>
</ControlTemplate>
</Window.Resources>
You can see we added a ControlTemplate which has a TargetType for our Pushpin objects. This we will bind to our Pushpins later. I’ve made the Pushpins look a bit like our TellUs logo and for this I needed a rectangle with rounded corners. Directly behind it I placed another rectangle that I skewed and rotated a bit to make it look a bit like a balloon. Then I added a ContentPresenter that should show the numerical value and I’ve also added some font settings to it. Nothing spectacular, but it’s nice if you know how to do it! ;-)
Now we move back to our code again and we need to do three things.
- Locate the control template for our Pushpin
- Bind it to our Pushpin
- Set the PositionOrigin of our PushPin.
This setting of the PositionOrigin is important to us, because our customized Pushpin should be placed to the top and to the right of where we click. I’ve included some code that we already had for additional clarity of where to put the code.
ControlTemplate template = (ControlTemplate)this.FindResource("CutomPushpinTemplate");
Pushpin pin = new Pushpin();
pin.Template = template;
pin.PositionOrigin = PositionOrigin.BottomLeft;
pin.Location = pinLocation;
pin.Content = counter += 10;
pin.MouseDown += new MouseButtonEventHandler(pin_MouseDown);
If we run our application again it should look like this after adding a few Pushpins and rotating them.
Adding custom styling based on content of the Pushpin
Now one really interesting thing to do is setting the size of the content/text of the Pushpin based on the number. If we start adding a lot of Pushpins this way and we start adding pins that have a numerical value of higher than 999, the font is too big so the value will fall outside of the boundaries of the pin.
For this we need a ValueConverter first. Based on the value that is inside the content of the Pushpin, we’ll return the FontSize. This FontSize then needs to be set to the style of the ContentPresenter. First let’s have a look at the ValueConverter. Add this directly beneath your MainWindow class, so that (in this tutorial) we don’t have the additional hassle of namespace problems.
public class PushPinContentConverter : IValueConverter
{
public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
int pushPinContentValue;
if (int.TryParse(value.ToString(), out pushPinContentValue))
{
if (pushPinContentValue >= 1000)
return 12;
else
return 15;
}
// If convert fails!
return 14;
}
public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
{
throw new NotImplementedException();
}
}
As you can see we try to extract the content from the Pushpin and if the value is higher than (or equally to) a 1000, we’ll lower the FontSize. Now we need to add this converter to the static resources of the Window in the xaml. First add a namespace reference (as seen in line 5) and then add it as a resource itself (as seen in line 9).
<Window x:Class="WpfApplication1.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:m="clr-namespace:Microsoft.Maps.MapControl.WPF;assembly=Microsoft.Maps.MapControl.WPF"
xmlns:local="clr-namespace:WpfApplication1"
Title="MainWindow" Width="700" Height="500">
<Window.Resources>
<local:PushPinContentConverter x:Key="MyContentConverter" />
Finally we need to add the styling to the ContentPresenter. The only thing changed is the element <ContentPresenter.Style> and the elements within it.
<ContentPresenter HorizontalAlignment="Center"
VerticalAlignment="Center"
Content="{TemplateBinding Content}"
ContentTemplate="{TemplateBinding ContentTemplate}"
Margin="0" TextBlock.FontFamily="Segoe UI" TextBlock.FontWeight="Bold" TextBlock.Foreground="#FFB8D30B">
<ContentPresenter.Style>
<Style>
<Setter Property="TextBlock.FontSize" Value="{Binding Path=Content, RelativeSource={RelativeSource TemplatedParent}, Converter={StaticResource MyContentConverter}}" />
</Style>
</ContentPresenter.Style>
</ContentPresenter>
I advise you to no start the counter variable at 0, but at 970, for your own testing pleasure. It’d be a whole lot of clicks if you started at 0 to see the results at Pushpin 1000 and higher.
Conclusion
All in all it is not so difficult to add a custom Pushpin, rotate it according to the map rotation and have the content sized based on its value. But information is fragmented and (for example) setting a ControlTemplate is mostly only shown in code if you start searching for it. I hope it’s beneficial for you to see it all in one place.
Download the entire solution here.
If this was usable, leave a comment and tell me your problems and/or results. Thanks!
We’ve had a lot of success applying the principles and practices of the Advanced Distributed Systems Design course into our project and Udi Dahan asked if I could shed some more light on how things played out for us, so here it is.
First of all, I wasn’t the only one who worked on this project - credit must also go to Sander Kooij and Maarten Vermeulen. Although I was the architect envisioning the solution, these guys were the ones that actually made it happen in code.
We work at Tellus, a global leader in lead generation. With current offices in Rotterdam, Los Angeles, London, Berlin and Sydney, Tellus serves over 100 countries and 10,000 businesses that depend on us to provide them high quality and high volume leads, no matter where or what industry.
Legacy
When we started out, we had to face quite a lot of legacy code. And if that wasn't enough, that code depended on one of the worst legacy databases I've ever seen. A lot of Udi Dahan's training is about dealing with and preventing coupling. For us, this legacy database was really where all the coupling was.
For a long, long time I believed the only way to get rid of that coupling was to start from scratch – a rewrite. This would be done by iteratively and incrementally building out features, releasing them, and improving from there. Eventually we’d get up to the point where we could remove the old legacy system. This path would've taken several developers at least a year of work, without any guarantees of success.
It was not until I’d taken Udi Dahan's course that I realized there were other ways. Udi describes a phased approach to restructuring old legacy code piece by piece while building out new and better designed components alongside them in a loosely coupled manner, all the while keeping the system still working.
I don’t want to make it sound easy. It was a long and hard process for us, but I’m convinced it was the better choice. This is why I was especially proud of our first major release. I am still working out better ways to manage our future transitions though, and digging into things like how much of what kind of documentation will be necessary and sufficient.
Maintainability
The current codebase is much more maintainable, being built of smaller modules that follow the Single Responsibility Principle, although what we’ve got goes much farther than that.
One of the problems Udi talks about in the course is hidden coupling between modules that talk to the same database. We really felt this pain in the legacy system where changing one part of it often ended up breaking other parts in totally unexpected ways.
I’m happy to say that we now have truly autonomous modules that each depend on their own database schema only, interacting with each other via publish/subscribe patterns. These “Business Components” enable us to modify and maintain each of them independently knowing that the chance of breaking code somewhere else is practically nonexistent.
There's no way we could have achieved this with the traditional layered service approach.
View Models and Events
One of the ways we had originally dealt with the deadlocks and performance issues plaguing our main database was by having stored procedures extract, transform, and load data to a different database – a “kind of” view model. While this helped a bit, we couldn’t run this process more than once a day as it took so long and hit the database quite hard. Unfortunately, this solution didn’t work that well for data that needed to be very fresh, like the customer data in our system.
For this reason, we avoided this kind of database-centric solution in the new components being built and made much deeper use of messaging and publish/subscribe patterns. It did take some time to make the transition, but we’re now seeing components publishing events even as they process other events received from different components – the kinds of “event cascades” Udi describes in his course.
Fast System Upgrades
Our original design had a component receiving events via publish/subscribe regarding a status update of our customers. When we deployed this to our test environment, the results were blazing fast and worked like a charm so I thought we could take things another step further.
Udi Dahan talks about the fallacy of centralization in the course and it really resonated with me. I realized we didn’t need to centralize this functionality just on the back-end server, so long as we had our deployment story organized.
What we did was to take the component deployed to the back-end and make it a part of our front-end web servers as well, enabling much earlier updates than before and a much better user experience. The really amazing thing was that we didn’t have to make any code changes for this – only our deployment scripts, and just like that we had it live on 24 web servers!
Watching this in action really put the daily legacy view-model update to shame and really proved to our business stakeholders the value of our approach. The publish/subscribe capabilities of NServiceBus really paid off here.
Change of requirements & fast redeployment
Just like many other projects, even before the first deployment, change requests started coming in. We decided not to put it off and went into production promising to make the changes soon after.
Since all the change requests were in a specific area of business and we had designed our system in such a way that all the code dealing with a specific business capability would be encapsulated in a single service, we knew that changing that code wouldn’t break functionality in any other service. While it was one thing hearing that theory during the course, seeing it in action across 25 servers was quite another.
By using messaging, queues, and publish/subscribe patterns, we were able to upgrade a core part of our system without touching any other parts – even those that it communicates with on an ongoing basis. During the short period of time that it was down, the queues took care of buffering the communication for that service without affecting anything else. The system as a whole was never really down.
This was a totally new experience for our company – an upgrade without downtime, even with the thousands of websites we’re running.
In Closing
If you have the opportunity of going on the Advanced Distributed Systems Design course, I’d really recommend it. It’s hard to summarize all the practical tidbits of information I got from the course but it really changed my perspective on what’s possible in software. If you live in The Netherlands and want an introduction, come to the DotNed meeting held on Thursday, september 27th at Macaw in Amsterdam.
While there’s so much more we’re looking to put into place, I’m really proud of how far we’ve come and hope you’ve enjoyed hearing about it.
Also – we’re hiring, so if you’d like to come join a great team of people who are actively pushing the envelope – contact us! Position is in the Van Nelle Factory in the beautiful city of Rotterdam in the Netherlands.
This is an old article by Ted Neward that I’ve been trying to find for ages, as the original website isn’t online anymore. Until I remember the WayBackMachine and found the original article. As the WayBackMachine doesn’t always remember (or keeps remembering) everything, I’m reposting the article here for safekeeping. If the owner ever decides that it should be up here but somewhere else, let me know. 
As many of you know, I've leveraged and extended "The Eight Fallacies of Distributed Computing" originally created by Peter Deutsch (and extended by James Gosling) to add two more and call them "The Ten Fallacies of Enterprise Computing" for the Effective Enterprise Java book. At the Reston, VA No Fluff Just Stuff Symposium, though, an attendee suggested, in response to an answer I gave, that perhaps I was missing one more, the 11th Fallacy:
11. Business logic can and should be centralized.
The reason this is a fallacy is because the term "business logic" is way too nebulous to nail down correctly, and because business logic tends to stretch out across client-, middle- and server- tiers, as well as across the presentation and data access/storage layers.
This is a hard one to swallow, I'll grant. Consider, for a moment, a simple business rule: a given person's name can be no longer than 40 characters. It's a fairly simple rule, and as such should have a fairly simple answer to the question: Where do we enforce this particular rule? Obviously we have a database schema behind the scenes where the data will be stored, and while we could use tables with every column set to be variable-length strings of up to 2000 characters or so (to allow for maximum flexibility in our storage), most developers choose not to. They'll cite a whole number of different reasons, but the most obvious one is also the most important--by using relational database constraints, the database can act as an automatic enforcer of business rules, such as the one that requires that names be no longer than 40 characters. Any violation of that rule will result in an error from the database.
Right here, right now, we have a violation of the "centralized business logic" rule. Even if the length of a person's name isn't what you consider a business rule, what about the rule stating that a person can have zero to one spouses as part of a family unit? That's obviously a more complicated rule, and usually results in a foreign key constraint on the database in turn. Another business rule enforced within the database.
Perhaps the rules simply need to stay out of the presentation layer, then. But even here we run into problems--how many of you have used a website application where all validation of form data entry happens on the server (instead of in the browser using script), usually one field at a time? This is the main drawback of enforcing presentation-related business rules at the middle- or server-tiers, in that it requires round trips back and forth to carry out. This hurts both performance and scalability of the system over time, yielding a poorer system as a result.
So where, exactly, did we get this fallacy in the first place? We get it from the old-style client/server applications and systems, where all the rules were sort of jumbled together, typically in the code that ran on the client tier. Then, when business logic code needed to change, it required a complete redeploy of the client-side application that ended up costing a fortune in both time and energy, assuming the change could even be done at all--the worst part was when certain elements of code were replicated multiple times all over the system. Changing one meant having to hunt down every place else a particular rule was--or worse, wasn't--being implemented.
This isn't to say that trying to make business logic maintainable over time isn't a good idea--far from it. But much of the driving force behind "centralize your business logic" was really a shrouded cry for "The Once and Only Once Rule" or the "Don't Repeat Yourself" principle. The problem is that we just lost sight of the forest for the trees, and ended up trying to obey the letter of the law, rather than its spirit and intentions.
Now, the question remains, is this a fallacy of all enterprise systems, worthy of inclusion in the fallacies list? Or is this just a fragment of something more? Much as I hate to admit it, I'm leaning towards the idea that it's worthy of inclusion (which means Addison-Wesley is going to kill me for trying to make a change this late in the game).
I’ve written in SDN Magazine about messaging and how it relates to RPC. It isn’t about messaging vs. RPC, but more or less an attempt to explain what benefits messaging can add to your software. Monday April 23rd I gave a presentation about the same subject. With this post I want to show the code so people can have a better look at it. Remember that there’s so much more possible than I show. I’m not going all the way, just showing how spatial coupling can be solved. Platform coupling is solved by WCF and nServiceBus self and temporal coupling can be achieved by doing it asynchronously over MSMQ, for example. nServiceBus does this by default, WCF can do this by marking operations as OneWay and selecting the msmqBinding.
So what did I show? First of all, let’s look at code that Visual Studio 2010 has in its WCF Service Application template. I sometimes get remarks that the info in a post is not complete, so here it goes
- Do File –> New Project
- Select “WCF” on the left and then the “WCF Service Application” template.
You can see IService1 interface with a method named “GetData” which expects a single parameter and returns a string value. The client knows the method to execute and when something changes, the coupling of the client to the service might break the client. Versioning is only on of the many problems that might hit you. This is the implementation in the Service1 class.
public string GetData(int value)
{
return string.Format("You entered: {0}", value);
}
Add a new Console Application to your solution, add a Service Reference without changing anything of the defaults. Then create the code to call this service. Your console application should look like this.
class Program
{
static void Main(string[] args)
{
ServiceReference1.Service1Client svc = new ServiceReference1.Service1Client();
string result = svc.GetData(10);
Console.WriteLine("Result : {0}", result);
}
}
So the idea is that we don’t create separate methods for everything we want to send, but rather have something in place that finds the correct handler class for our message. So what we need is a single generic method in our service contract that accepts anything that conforms to a message we specify. Add the following method to your IService1 interface and make sure your code compiles. This means you’ll have to implement the method in the Service1 class.
[OperationContract]
void Execute(Message message);
As you can see we specified the class Message as parameter so we’ll need to define it as well.
public class Message
{
}
Now the Execute method on our Service1 class needs to call a handler class that will contain our code. We’ll specify a default interface so that all our handlers adhere to this interface. That way we’ll be able to easily find all handlers via reflection. Let’s have a look at the interface.
public interface IHandleMessages<T> where T : Message
{
void Handle(T message);
}
Now all we need to do is create a real message and a handler that will be able to work with this message.
public class GameOfTheYear : Message
{
public string Name { get; set; }
public int Year { get; set; }
}
public class GameOfTheYearHandler : IHandleMessages<GameOfTheYear>
{
public void Handle(GameOfTheYear message)
{
Debug.WriteLine("Game : " + message.Name);
}
}
The message is quite simple and the implementation of our handler maybe even simpler. But these aren’t the point currently. What is important is how we actually execute the Handle method from our service. Here’s the code for it and we’ll go through it line by line.
public void Execute(Message message)
{
Assembly assembly = (message.GetType()).Assembly;
var allMessageHandlers =
from type in assembly.GetTypes()
where !type.IsAbstract
from interfaceType in type.GetInterfaces()
where interfaceType.IsGenericType
where interfaceType.GetGenericTypeDefinition() == typeof(IHandleMessages<>)
select type;
Type messageInterface = typeof(IHandleMessages<>).MakeGenericType(message.GetType());
var myMessageHandlers = allMessageHandlers
.Where(type => type.GetInterfaces()
.Any(it => it == messageInterface))
.Distinct();
foreach (var handler in myMessageHandlers)
{
object handlerInstance = Activator.CreateInstance(handler);
MethodInfo methodInfo = handler.GetMethod("Handle");
methodInfo.Invoke(handlerInstance, new[] { message });
}
}
At line 3 we get the assembly of the message we’ve received. This is part of the convention over configuration you can use, which states that the handler for the message should be in the same handler. Of course you could scan every single assembly in the same folder as you. For performance benefits you can scan it a single time and store all handlers and its methods in memory. Again, we’re keeping it simple so it’s easier to understand. At line 5 we’re searching for all types that are not abstract (line 7), implement a generic interface (line 9) that are of type IHandleMessages (line 10).
Then in line 13 we compose a type of the generic IHandleMessages interface with the type of our message. In line 14 we filter our just selected handlers so that we’ll only have the ones that actually implement our exact interface. Now that we have our actual handlers, we can try to create an instance of it (line 21), find the Handle method and invoke it with our message as its parameter.
Now refresh your ServiceReference in your console application client by right-clicking the service reference and selecting the update item in the context menu. Now you should be able to create a GameOfTheYear object. However, although our service does recognize the “Execute” method, it has no knowledge of the GameOfTheYear class. This simply is because WCF doesn’t automatically provides every single class in its WSDL/MEX-endpoint so we need to provide this information to it. Open the IService1 interface again and change the contract for our Execute method so it looks like this.
[OperationContract]
[ServiceKnownType("GetKnownTypes", typeof(MessageTypeFinder))]
void Execute(Message message);
Now recompile the project and update the service reference again. Everything should work flawlessly again. If this works, we can try to see if we can do something very valuable; create an additional handler that logs our messages to disk.
public class GameOfTheYearLogHandler : IHandleMessages<GameOfTheYear>
{
public void Handle(GameOfTheYear message)
{
Logger.Write("We've processed " + message.Name);
}
}
The same code will execute both handlers without any changes. We’ve really decoupled the execution and handling of the message we’re sending from the initial service. As you can see we can create multiple handlers for a single message. What we can also do is create a single handler for multiple messages. We’ll first define the message and add an additional interface to our GameOfTheYearHandler.
public class GameReview : Message
{
public string NameOfGame { get; set; }
public string Review { get; set; }
}
public class GameOfTheYearHandler : IHandleMessages<GameOfTheYear>, IHandleMessages<GameReview>
{
public void Handle(GameOfTheYear message)
{
Console.WriteLine("Game : " + message.Name);
}
public void Handle(GameReview message)
{
Console.WriteLine("Revied : " + message.NameOfGame);
}
}
First thing to remember is that we need to make sure the GameReview message is specified as a KnownType to our service. As we don’t want many lines with ServiceKnownTypeAttribute statements there, we need a different solution. Add the following class to your code and then replace the original ServiceKnownType line with the last line in the following code.
public class MessageTypeFinder
{
public static IEnumerable<Type> GetKnownTypes(ICustomAttributeProvider provider)
{
IEnumerable<Type> query =
from type in typeof(Message).Assembly.GetTypes()
where typeof(Message).IsAssignableFrom(type)
select type;
return query.ToArray();
}
}
[ServiceKnownType("GetKnownTypes", typeof(MessageTypeFinder))]
Now we only need to tweak the execution of the handlers in the foreach loop to the following code.
foreach (var handler in myMessageHandlers)
{
var methods = from m in handler.GetMethods()
where m.Name == "Handle"
from p in m.GetParameters()
where p.ParameterType == message.GetType()
select m;
object handlerInstance = Activator.CreateInstance(handler);
var methodInfo = methods.Single();
methodInfo.Invoke(handlerInstance, new[] { message });
}
We can’t simply select the Execute method anymore, as there are multiple. So we’re checking the parameter type and see if it’s the same type as our incoming message. There obviously cannot be more than one method with the exact same parameters, so we can select Single() on line 10 and then we’ll be able to execute the method.
FYI: During the SDN event I forgot to create the actual instance of the handler and was trying to execute the Handle method on the type. This is obviously not possible. So now you know why it didn’t work during the presentation.
nServiceBus
So during the presentation I also mentioned nServiceBus. If you look at the code you need to write to use nServiceBus, this is exactly the handlers and messages as I’ve shown in the code above. However with nServiceBus you can use interfaces as messages so you can create message with complex inheritance trees. A method to “initiate” an interface is provided, which creates a proxy which you can then fill with your information. Since version 3.0 of nServiceBus you no longer need to implement the IMessage interface on your messages which makes creating libraries with messages that are shared, much easier, since you don’t need an assembly reference to nServiceBus anymore.
Of course we have no need to write plumbing code, as nServiceBus has done this all for you.
- Transactions are supported in WCF, but with nServiceBus everything is transactional by default.
- As said, in WCF you can mark messages OneWay and select the msmqBinding to use msmq. nServiceBus does this by default.
- nServiceBus makes it possible to do request/reply asynchronously. Due to the nature of queuing, it’s not possible to immediately send a response. The sending application however can specify a return queue in it’s message (nServiceBus does this for you) and with a Bus.Reply(myMessage) you send the return message.
- Retry of message is supported with a variable amount of retries. After final failure the messages get enriched with exception information and transferred to a (configurable) error queue.
- Publish/Subscribe is possible where one publisher has no knowledge of any clients receiving the messages. A variable number of clients can subscribe to the messages and nServiceBus takes care of subscriptions. Since version 3.0 you can store these in RavenDB.
- Long running processes (called sagas) are supported where you can wait for multiple incoming messages before continuing.
- Timeouts are supported so when within a saga messaging don’t arrive on time, you can send yourself a warning. Since version 3.0 you can also send messages to yourself in the future. These messages don’t arrive before the time you specified.
Conclusion
Again, messaging isn’t the silver bullet to your problems. It is however another way to communicate out of process to other applications or business components. It should provide additional options to implement without your architecture and you should seriously consider it if you haven’t used messaging and/or queuing frameworks before. Messaging has a lot of additional perks which I wrote about in my SDN article. When the new magazine arrives, I’ll post the PDF on my weblog. Until then, you are allowed to contact me and request the article.
Download the source here.
Microsoft Patterns & Practices team has started a journey to CQRS with the idea to create a guidance document to provide developers with a map that will help them find a way with the Command and Query Responsibility Segregation (CQRS) and Event Sourcing (ES) patterns and related techniques. Everything is extremely public and a lot of information about the journey can be found here on GitHub.
As a member of the Advisory Board it’s been a journey of my own. It’s really great to see a lot of opinions and discussions happen during the conference calls with the advisory board. The journey is really taking form and more documentation is put online every two week sprint. Also code is available for download so you can see what is happening over time. Every sprint is also shortly documented on the github site, so you get an idea what was achieved.
Last meeting a discussion was started by Udi Dahan that too little effort was put in thinking properly about the domain so that BC’s (be it Bounded Contexts in DDD, Services in SOA or Business Components by others) weren’t properly modelled. He wrote a lengthy post about it with some additional information in another post. When you’ve been to his Advanced Distributed Systems Design course you will understand his problems with this, as it’s a very crucial part of the architecture he proposes. This isn’t a silver bullet architecture from a technical perspective, as you have all kinds of technical options to solve every single Business Component and Autonomous Component as you see fit. But it’s very important from a functional perspective and helps solve a whole lot of problems related to coupling of information. Which in turn should make things a whole lot easier to solve when maintaining the system or adding new features to it.
After trying to enhance our current system at Tellus and making steps to enhance it according to these ideas, I’m still very, very enthusiastic about this approach. If you ever want to talk about the possibilities or ideas, please don’t hesitate to contact me. I’d love to come by or invite you over to the Van Nelle factory to talk about it and show you what we’re doing. Of course I am equally interested in how other companies solve problems like ours. Let me know via the contact form.
It’s the small things that easily make me a happy boy. Adding a unit test to a test project is easier via the context menu. Also the class that is generated from the template is very clean and doesn’t contain the TestContext and commented-out functions anymore. Using those functions is a bad practice anyway. But about a minute after installing Visual Studio 11 I’m already happy to work with it.
This blogpost is part of a series
- Template Method Pattern explanation
- Template Method Pattern example
- Template Method Pattern advanced
So we’ve looked at the Template Method Pattern with an implementation as really simple example, and another real world implementation. We have additional requirements however. We also need to transform the template so that placeholders will contain the proper text, and have the value of the placeholders customized to our customers. Let’s first look again at the executing code, so we get an idea of what API we want.
static void Main(string[] args)
{
TemplatedMessage message = new TemplatedMessage();
message.Identifier = Guid.NewGuid();
message.EmailAddress = "dvdstelt@gmail.com";
message.Template = "So you're a {{Sex}} and like to play {{BestGameEver}}.";
message.PlaceHolders.Add("Sex", "male");
message.PlaceHolders.Add("BestGameEver", "Modern Warfare 3");
MessageSenderBase emailMessageSender = new EmailMessageSender();
emailMessageSender = new MessageSenderPlaceholderParserDecorator(emailMessageSender);
emailMessageSender = new MessageSenderPlaceholderFormatterDecorator(emailMessageSender);
List<MessageSenderBase> MessageSenders = new List<MessageSenderBase>();
MessageSenders.Add(emailMessageSender);
MessageSenders.Add(new HttpPostMessageSender());
foreach (var sender in MessageSenders)
{
sender.Execute(message);
Console.WriteLine("");
}
Console.WriteLine("The final message is:\n{0}", message.Template);
Console.WriteLine("\n\nDone...\n\n");
}
It’s exactly the same code, with some additional lines added to it.
- Line 6 shows a new template in the message. You can see the placeholders {{Sex}} and {{BestGameEver}}.
- Line 8 & 9 show an additional property in the TemplatedMessage, knowing PlaceHolders, which is of type Dictionary<string, string>
- Line 11 shows the initialization of the EmailMessageSender, which hasn’t changed since last post.
- Line 12 shows the initialization of a decorator, to parse the placeholders and put in proper text from the PlaceHolders dictionary. As the decorator pattern defines, this decorator wraps the MessageSender originally used.
- Line 13 shows an additional decorator, which replaces values that our customer doesn’t understand. Our customer doesn’t understand “male”, so the MessageSenderPlaceHolderFormatterDecorator replaces its values.
- Line 16 shows the previously instantiated EmailMessageSender being added, wrapped by two decorators.
Decorator pattern and a rewrite of the template method
So without changing anything in the current MessageSenderBase class or derivates, we want to add additional functionality to perform the parsing and formatting of the placeholders. I chose to implement the decorator pattern, which is a wrapper around the original class, where both have the exact same interface. A really nice decorator example of it can be found on Ruchit Surati his weblog.
The decorator normally has an interface with a public method. Every class that implements this interface has to implement the method, as do the decorators. Our public method is the Execute method, so we’ll override that method. In the original base class, it was the template method, calling the abstract methods Initialize, SendLead and Cleanup. We don’t need this behavior anymore, so we’ll break it. Instead, we’ll use it again to recreate it as an alternative template method. We’ll now make it call a new abstract method called Decorate and after that, run the Execute method on the MessageSender we are wrapping. We’ll also override and seal the SendMessage method, because our decorators never send messages.
The end result is shown in the Visual Studio class diagram below. Normal UML diagrams show the association from the MessageSenderDecorator to the MessageSenderBase a bit clearer; Visual Studio shows it as either a reference without a property, or a property without a clear reference. I’m mentioning this because from the perspective of the decorator pattern, this is an important reference. It shows the intent that we wrap the original MessageSender inside our decorator.
The code for the decorator base class.
public abstract class MessageSenderDecorator : MessageSenderBase
{
protected MessageSenderBase MessageSender { get; private set; }
public MessageSenderDecorator(MessageSenderBase messageSender)
{
MessageSender = messageSender;
}
// This method needs concrete implementation
protected abstract void Decorate(TemplatedMessage message);
// Close the SendMessage method, decorators don't send messages!
protected sealed override void SendMessage() { }
public override void Execute(TemplatedMessage message)
{
Decorate(message);
MessageSender.Execute(message);
}
}
Now we’ll implement the first decorator.
public class MessageSenderPlaceholderParserDecorator : MessageSenderDecorator
{
public MessageSenderPlaceholderParserDecorator(MessageSenderBase messageSender) : base(messageSender) { }
protected override void Decorate(TemplatedMessage message)
{
message.Template = ParseTemplate(message.Template, message.PlaceHolders);
}
private string ParseTemplate(string template, Dictionary<string, string> placeHolders)
{
foreach (var placeholder in placeHolders)
{
var key = string.Format("{{{{{0}}}}}", placeholder.Key);
var value = placeholder.Value.ToString();
template = template.Replace(key, value);
}
return template;
}
}
As you can see, our real decorator implementation now implements the Decorate method, which we had to implement based on our base class. What this class do is simply replace every placeholder with the actual value. Going back to our first code snippet of the static Main method, you can see that we first wrap the EmailMessageSender into the decorator to parse all placeholders. Then we wrap it inside the second decorator, for parsing all values of the placeholders. If we turn this around, first the template message will be parsed, and only then the values in the PlaceHolders dictionary will be replace. This is of course too late, and this is a bit of a downside to the decorator. When writing completely procedural code, not many developers would make this mistake. With the decorator pattern, you’ll have to think a bit about it. The intent here isn’t as clear as you’d want it to be.
Conclusion
It’s always hard for new developers to write software like this. From my own experience, when first coming into contact with design patterns, you start to search for a design pattern based on a problem you have. After a lot of experience with some design patterns, you’ll start thinking the other way around. Instead of starting with a problem and finding a good design pattern that solves it, you’ll immediately start thinking about a design pattern that matches the problem you’re solving. Again, this is experience and takes practice. Try playing around with design patterns until you know them and know what they do. It’s not that important to be able to draw them out in a UML class diagram, from the top of your head. As long as you can remember which problems they solve and how you should roughly implement them.
Speaking of finding the right design pattern for a problem; this could very likely be solved in multiple ways, with different patterns. But it’s an example of how a problem could be solved using design patterns. I still have to completely implement this into our system and might come up with alternate solutions altogether. But I started this as a proof of concept and it seemed nice enough to blog about it. I hope you learned something from it, because that is still the reason for me to blog! ;-)
Download the source here.
This blogpost is part of a series
- Template Method Pattern explanation
- Template Method Pattern example
- Template Method Pattern advanced
So in my previous post I explained how I change the template method pattern a bit with protected abstract methods. In this post I’ll explain why I used this pattern and how I chose to implement it.
Requirements
At my current employer we send a lot of messages to customers. It varies per customer how message are being send. Some want a simple email, others want an xml document in their email, others want an xml document over HttpPost and others want us to send the message directly into a customers system, for example SalesForce. Most customers only have one option, some customers want multiple options.
When the software was first build, we only did send messages via email. A very simple solution was build. As more and more variations were required, a better solution was required. In our system, information is gathered, which is being inserted into the messages we send. We needed templated messages which contain placeholders. However, as some customers receive XML fed directly into their system, we needed to change some placeholder values, as not every system understands our values “male” and “female”, but rather have “1” or “0” for these values. Technical requirements are also important. We need to be able to store a successful or failed result to a datastore and needed to log exceptions as well.
First, we’ll have a look at how we solve different transport mechanisms. Additional requirements for templates will be explained in another post, where we’ll add the decorator pattern and implement an additional template method pattern.
Perhaps you’ll understand better what I implemented, if I show you the code that is executed to actually send out everything. In our system, we dynamically define which modules are being executed, in the following code I’ve defined a message sender for email and HttpPost.
static void Main(string[] args)
{
TemplatedMessage message = new TemplatedMessage();
message.Identifier = Guid.NewGuid();
message.EmailAddress = "dvdstelt@gmail.com";
message.Template = "Dude!";
List<MessageSenderBase> MessageSenders = new List<MessageSenderBase>();
MessageSenders.Add(new EmailMessageSender());
MessageSenders.Add(new HttpPostMessageSender());
foreach (var sender in MessageSenders)
{
sender.Execute(message);
}
Console.WriteLine("\n\nDone...\n\n");
}
First the message is defined. It contains a guid for reference, an email address and a template. The template is the actual message. Then we initialize the two message senders and execute these one at a time in the foreach loop. Let’s have a look at the implementation of the base class.
public abstract class MessageSenderBase
{
protected TemplatedMessage Message { get; private set; }
public virtual void Execute(TemplatedMessage message)
{
Message = message;
Initialize();
SendMessage();
CleanUp();
}
protected abstract void SendMessage();
private void Initialize()
{
if (Message == null) throw new InvalidOperationException("Message cannot be null");
Console.WriteLine("Initializing {0} for MessageId [{1}].", this.GetType().Name, Message.Identifier);
}
private void CleanUp()
{
Console.WriteLine("Cleaning up {0} for MessageId [{1}].", this.GetType().Name, Message.Identifier);
Console.WriteLine("\tSaving state changes to datastore...");
Console.WriteLine("\tSaving result to logfile...");
}
}
The base class of course cannot be instantiated, so we made it abstract. The message that was created in the first codeblock, is stored in a protected property (line 3), so we don’t have to pass it to every single method. Normally I don’t like vague global variables, but as it’s protected, I don’t see real harm. The SendMessage method is the abstract method that the derived classes must use to write code that they are responsible for. The Initialize method has a guard for a proper message, some might want this to be in the Execute method.
The Initialize and CleanUp method don’t do anything in the above code, but normally you’d use those for logging, storing state and exception handling. We have Enterprise Library code there for logging, and we log the current progress to a trace listener, rolling textfile and database. With the regular trace listener we can use DebugView from Sysinternals for live tracing.
The Execute method is the only public method. It is the method that will be executed and used to run every method in the right order. This will always run the SendMessage method of a derived class, simply because this base class has no implementation. So let’s have a look at our email sender.
public class EmailMessageSender : MessageSenderBase
{
protected override void SendMessage()
{
Console.WriteLine("I'm sending the message via email.");
}
}
This could not be a lot simpler. Of course the actual implementation isn’t here, but that’s the point of the example. There’s no other code in this class, but the code that’s related to sending the message over email. This is completely according to the Single Responsibility Principle. When a customer requires an additional way of sending the message, we don’t need to change any code. We simply add another class with the required functionality. That’s Open/Closed Principle for you!
I hope you understand why I like this implementation of the Template Method Pattern. For deriving classes, it’s completely clear what to implement. For external applications, it’s completely clear what to execute. In the last part of the Template Method Pattern series, we’ll introduce additional functionality and solve one problem with the decorator pattern and another template method pattern implementation. That post also includes a download if you want to play around with the code.
More Posts
Next page »