Author Archive
Validation in Domain Driven Design
There’s a great discussion on Jeff Palermo’s blog about entity validation patterns. Jeff takes the position that your domain objects (or entities) should not have validation logic “baked-in” to the class itself. Instead, you should separate the validation routines into separate classes that you can use to validate the object on demand.
There are two advantages to this approach. The first is that you can use different validators for the same object in different circumstances. For example, the validation you might perform prior to storing the domain object in a persistence layer could be different than the validation routine used to validate input from the GUI layer.
The second advantage is that separating the validation logic from the data itself makes it easier to work with ORM or serialization frameworks. Most of these frameworks encourage the use of Plain Old Objects, that is, objects without special attributes or interfaces that help with these mapping and serialization tasks. (See Wikipedia’s article on Plain Old Java Objects, for example.)
Those are powerful arguments, but I’m still not convinced.
Trade-offs
As a practical matter, Jeff’s advice is sound. It’s much easier to move business logic into the helper classes that surround your entity model. You get better tool support and more flexibility. But there’s two things about his approach that bother me. Judging by some of the excellent comments on his article, other programmers are bothered by them as well.
First, stripping away behavior from your domain objects is a recognized anti-pattern in object oriented code. Martin Fowler calls it the Anemic Domain Model. It harkens back to the days of procedural programming, where data and business logic were strictly separated. If you’re an OO purist, this is a red flag.
From an OO perspective, the need to validate the same object in different ways suggests that what you actually need to do is create more objects. Rather than pass a stripped-down data-transfer object (DTO) all the way from your data storage layer up to your GUI, you should have a bunch of intermediate objects to help transition the data and enforce proper behavior.
But I’m not an OO snob. Writing a whole bunch of extra classes to move information between tiers in my application is a hassle. I’ve done it before, and we’re doing it now with Infovark, but for most projects it just isn’t justified. Especially if you have to wrestle with various application frameworks to deal with correctly modeled but more complicated domain objects.
The second objection I have is that if we follow Jeff’s advice, we have to accept that bad data will creep into our domain. Jeff knows that this is a hard sell. It’s why he titled his article “The fallacy of the always-valid entity.”
Whew. That’s rough. That requires a whole different programming mindset. What about the problem of Garbage In, Garbage Out? Can we really create programs robust enough to handle business objects that might, at any moment, contain meaningless gibberish?
I don’t know. For now, as appealing as Jeff’s idea is, I’ll stick to always-valid approach. What do you think?
Review: Framework Design Guidelines
Framework Design Guidelines
I’m almost embarrassed to admit that I really enjoyed Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams. I mean, it’s a book about coding standards.
Maybe I ought to get out more… but before I leave the glare of my monitor behind, I’ll type up my review.
Code is literature, not language
Computing languages, just like human languages, have grammar and syntax. There are correct ways to form sentences and paragraphs, with well-defined rules (and exceptions). Just like word processors can check spelling and verify basic sentence structure, most IDEs today can ensure your code will compile and run.
That doesn’t mean that your story or program is an easy or enjoyable read, though. Most newspapers have accumulated extensive guidelines for matters of style and substance, and most software companies have their own guides as well. If you’re writing as part of a team project, or writing programs intended to be used by other programmers, it’s important to make your code consistent, clear, and direct.
Just like many journalists keep a copy of The Associated Press Stylebook or the New York Times Manual of Style and Usage handy — even if they don’t actually work for the New York Times or the AP — lots of programmers keep a copy of Microsoft’s Framework Design Guidelines as reference.
Or they should. That’s probably my roots as a maintenance programmer showing.
Know your genre
Ideally, you’d want any code you write for other Windows programmers’ use to look as if it came from Microsoft itself. That is, you want it to feel like a natural extension of the .NET framework and not some third-party bolt-on with odd stylistic touches. You’d also like your code to use the full power and expressiveness of .NET, and not appear like some watered-down Java-esque port. (Far too many open source projects retain awkward Java-isms after being converted to .NET, in my opinion. NUnit is a notable exception.)
This helps your fellow programmers gain a better understanding of your code in less time. And it can also make your programming tasks easier, too. Just like design patterns can help you lay out your application architecture, programming guidelines can help you structure your code at the class or method level.
About the book
The Framework Design Guidelines covers a lot of ground in its 400 pages. It describes what conventions Microsoft uses when designing types, methods, and exceptions. It also describes the naming and design patterns that Microsoft uses in their public APIs. The topics are grouped by category and heavily cross referenced, making it easy to find your way around. The rationale of each guideline is explained, and the authors indicate the strength of each recommendation by marking it with the terms Do, Consider, Avoid or Do Not.
But the best part of the book is the stories and comments given by members of the Microsoft team. These are sprinkled throughout the book and give insight into why the guideline exists. Some of these discuss lessons Microsoft learned the hard way, places in the .NET Framework where the rules are violated, and how real-world programmers feel about certain guidelines. You can get a flavor of these by checking out the Framework Design Guidelines section of Brad Abrams‘ blog.
If you find his posts interesting or helpful, you’ll feel the same way about the book. Highly recommended.
The Times, They Are A-Changin’
Recently, I made a plea for the adoption of Universal Coordinated Time (UTC) in computer applications. It’s a sensible recommendation, and I stand behind it.
The folks working on HTML 5 are proposing a <time> element for the new standard. This makes sense to me. It will help eliminate some of the objections people have raised to the datetime design pattern proposed by the microformats team.
So, problem solved, right? We use UTC for time, and the usual calendar notation for dates. Neat.
Wait a minute. By “the usual” calendar notation, do we mean the modern Gregorian calendar, or…
There’s always a catch
Peter-Paul Koch, a.k.a. PPK, author of the quirksmode blog, reminds us that calculating historical calendar dates is hard. Really, really hard.
He provides an overview of the major calendar reforms in the Western world and points out that the reforms were adopted by different countries at different times. So forming a consistent timeline requires a knowledge of both time and place.
And many important historical dates float. The rules that determine when Easter occurs in the church calendar are complicated, and Orthodox and Catholic calendars disagreed for many years. In the medieval period, years were often numbered according to the local monarch’s reign. In Roman times, extra days were added to the official calendar by decree to prevent the seasons from drifting too far out of line.
If we want to make the <time> element safe for historical use, programmers would have to deal with this mess.
Leave it to the historians
As useful as having universal, consistent <time> element metadata would be, that’s just too hard. Frankly, I skimmed the last bits of PPK’s article myself, and I’m actually interested in the issue. Most working programmers won’t bother.
While it’d be nice to have trustworthy time data, we’re not likely to get it. The standard should reflect that. I vote for assigning a cutoff date for the <time> element. January 1, 1970 works for me.
Tools: Firebird Maestro
I didn’t set out to buy a SQL IDE three months ago, but I bought Firebird Maestro from the SQL Maestro group anyway.
What I was looking for
What I was actually looking for was an equivalent to Red Gate‘s SQL Packager for the Firebird database. SQL Packager is a useful application that makes it easy to package and deploy database schema upgrades. Sadly, all of Red Gate’s tools are for Microsoft SQL Server only.
My next step was to look through the list of admin tools on the Firebird website. And while there’s a huge selection of tools available for Firebird, I couldn’t find anything that would help me deploy schema and data upgrades. It was a bit surprising, actually, since one of Firebird’s strengths is how easy it is to embed inside other software applications. (If I’ve missed an application that can do this, please let me know!)
What I found instead
During the course of my investigations, I downloaded several different tools for managing Firebird. I’m a fan of the fast and free FlameRobin, but it’s still in development and doesn’t do everything I need. Sometimes a full-featured IDE is required, and I found two that fit the profile.
The first was SQL Studio from EMS Database Management Solutions. I appreciated their customer support and the breadth of features. But ultimately, I decided upon Firebird Maestro. The differences between the two IDEs were small, but Firebird Maestro had a better tool for producing database diagrams. Since Infovark has developers working halfway around the world from each other, having a good database diagram to reference is a must. Firebird Maestro also had a simple wizard for scripting out the schema and data into a single file. We put this text file into Subversion so that we have our database structure under version control.
Firebird Maestro
It won’t help me deploy an update, but I’ve had to do that sort of thing by hand before, and I suppose I can do it again. But sometimes when you look for something you find something else just as good.
Visual Studio 2008 and its CopyLocal setting
Our build server wasn’t producing the same results as our local development machines. The same C# code yielded two different sets of code libraries. After much head-banging and hand-wringing, we finally traced the problem to an obscure error in the way Visual Studio 2008 handles .csproj files.
Basically, the Visual Studio IDE doesn’t handle the CopyLocal setting properly. This post from paraesthesia set us on the right track.
I have no idea what caused the problem. We had the same versions of the .NET Framework and Visual Studio 2008 installed on all our machines. The code was exactly the same. Apart from the build machine being Windows Server 2003 and out development machines being Windows XP, I can’t think of any other differences. But somehow the code libraries weren’t getting copied in the same way.
Just another adventure on our way toward the Beta release…
REST: How to respond to an HTTP POST
I ran into a problem yesterday. I’d sent a HTTP POST request to a collection of resources on our RESTful web service. Our server responded with an HTTP 201: Created status code and the URI of the new resource in the Location header.
And then… nothing happened.
This was not what I was expecting. I expected my web browser to follow up with a GET request to the URI I’d provided. But Firefox 3 wasn’t biting. A problem with Firefox? I checked in IE8 and Google Chrome and got the same behavior.
Had I misread the HTTP spec? Did I misunderstand the REST pattern? I grabbed for my worn copy of RESTful Web Services. Nope. HTTP 201 seemed to be the right status for this situation.
Had I blundered into some common error? I checked Stefan Tilkov’s useful list of REST Antipatterns. But I couldn’t find anything that quite matched my situation.
I started Googling, but couldn’t find much apart from this question about HTTP Post on Stack Overflow. There were some cryptic responses (to which I’ve added my own answer now).
Eventually, I discovered what I needed to know from Ben Ramsey’s article on HTTP redirection. It’s part of his series discussing RFC 2616, which describes the HTTP/1.1 protocol.
The answer is that while web service clients will often “take the hint” provided by a HTTP 201: Created response, web browsers won’t. If you actually want a web browser to go somewhere else, you need to send a status code in the 3xx series. In this situation, the status code you want is HTTP 303: See Other.
Once I changed the status code returned by the server, all the web browsers followed up the response with a GET to the new URI.
WCF WebInvoke Body Format Error
I spent Sunday afternoon battling an odd WCF error.
System.InvalidOperationException: Incoming message for operation [your operation here] contains an unrecognized http body format value ‘Xml’. The expected body format value is ‘Raw’. This can be because a WebContentTypeMapper has not been configured on the binding. See the documentation of WebContentTypeMapper for more details.
Troubleshooting this issue sucked. Here’s the deal: WCF helpfully attempts to parse any incoming “text/xml” requests automatically. If you’ve defined the input parameter on a WebInvoke operation to be a Stream, WCF can’t bind to the method and returns an HTTP 400.
There’s two ways to solve this problem: Change the input parameter from Stream to XmlElement, or configure WCF to treat this request as Raw. I picked the former method. Carlos Figueira explains the latter method.
If folks are interested, I can post some more detail about the problem and the resolution. For now, I have to finish making things work.
Edit: So here’s the rest of the story, since Brad asked.
I wasn’t sure exactly what triggered the issue. I got this behavior with just one WebInvoke and one WebGet operation using the same URI template. What I’d done was to create a generic ObjectService that exposed the same RESTian operations for several different types of objects. The particular operation in question looked something like this:
-
[OperationContract]
-
[WebGet(UriTemplate = ItemUris.IndexXml, RequestFormat = WebMessageFormat.Xml, ResponseFormat = WebMessageFormat.Xml)]
-
Stream GetListAsXml();
-
-
[OperationContract]
-
[WebInvoke(UriTemplate = ItemUris.IndexXml, Method = "POST", BodyStyle = WebMessageBodyStyle.Bare, RequestFormat = WebMessageFormat.Xml, ResponseFormat = WebMessageFormat.Xml)]
-
Stream PostListAsXml(XmlElement input);
Originally, PostListAsXml had accepted a Stream. That seemed to work in other places, but then I started noticing the InvalidOperationException messages.
I think the right way to solve this problem is to follow Carlos’ advice, and create a new WebContentTypeMapper-derived class. But I didn’t have time to figure out exactly where to plug it in, and I was afraid that I might introduce other problems. I just didn’t know enough about the inner workings of WCF to know whether that was a safe operation.
Since we hadn’t shipped the interface yet, I was free to change the return type from Stream to XmlElement for the one or two WebInvoke operations that were returning errors. Fewer lines of code needed to change, and I knew I wouldn’t break anything else.
Of course, I’m probably just setting myself up for more pain down the road, but sometimes you just need to get things done, y’know?
Anyway, since I’ll likely revisit this decision in a later release, I’d love to hear what other folks did in this situation.
Using WCF to return HTML
I just answered a WCF question on StackOverflow, and decided it was worth cross-posting here as well.
The question was: What is the best / most flexible way to have WCF output XHTML?
Here’s how we do it at Infovark. While I’m not sure that our approach is the best way, it does the job.
Our approach is to use the DataContractSerilizer to generate XML, then apply a Complied XSLT transform and return the result stream, which should now contain XHTML. Here’s a simplified version of our code:
-
public Stream GetItemAsHtml(string id) {
-
Item obj = GetItem(objectId);
-
Stream xml = GetXmlStream(obj);
-
return TransformXmlStream(xml, defaultTransform);
-
}
-
-
public static Stream GetXmlStream(IXmlSerializable item) {
-
MemoryStream stream = new MemoryStream();
-
using (XmlWriter writer = XmlWriter.Create(stream, new XmlWriterSettings { Encoding = Encoding.UTF8 })) {
-
if (writer != null) {
-
DataContractSerializer dcs = new DataContractSerializer(item.GetType());
-
dcs.WriteObject(writer, item);
-
-
writer.Flush();
-
writer.Close();
-
}
-
}
-
stream.Seek(0, SeekOrigin.Begin);
-
return stream;
-
}
-
-
public static Stream TransformXmlStream(Stream xml, string xsltFile) {
-
XmlReader reader = XmlReader.Create(xml);
-
-
XslCompiledTransform trans = new XslCompiledTransform();
-
trans.Load(xsltFile);
-
-
MemoryStream stream = new MemoryStream();
-
using (XmlWriter writer = XmlWriter.Create(stream, trans.OutputSettings)) {
-
if (writer != null) {
-
trans.Transform(reader, writer);
-
-
writer.Flush();
-
writer.Close();
-
}
-
}
-
stream.Seek(0, SeekOrigin.Begin);
-
return stream;
-
}
It works for us, but if you’ve got other, better ideas, please let me know!
Put the “Web” Back in Web Services
I know it’s possible to transmit Internet Protocol by carrier pigeon, but I’m not sure I could recommend it to our customers with a straight face. By the same token, I’m continually surprised to hear vendors and consultants insist that Web Services can be done without the web.
Yet I’ve seen that claim repeated all over the Internet. Sure, it’s true in the academic sense. Technically, there’s nothing wrong with “webless” web services, just like IP by avian carrier will eventually get the job done (though latency and packet loss are a challenge). But practically speaking, why would you use anything other than HTTP?
The “webless web services” meme has infected a number of good ideas. The SOAP standard is a case in point. At first, SOAP was a simple XML wrapper around an XML payload. (Remember when the S in SOAP stood for Simple?) Then a variety of industry heavyweights jumped on the bandwagon, and soon SOAP could be used with any protocol.
With, uh, a few changes. Like five or six additional specifications. And schema. Lots of schema. Maybe a diagram would help? No?
Why not use REST instead?
Nicholas Allen recently shared a great presentation on REST and SOA given by Stefan Tilkov at QCon. Stefan makes some great points about how RESTful web service design aligns well with the goals of Service Oriented Architecture (SOA).
Sure, you could use the WS-* stack if you like, but RESTful web architecture is a proven, scalable and truly simple approach, as long as you don’t mind having to use HTTP.
Much of the added plumbing in the WS-* stack is there to help transition older computer-to-computer network communication technologies. It allows applications that depend on CORBA or DCOM to tunnel through firewalls. But unless you’re trying to retrofit a system built before, say, 1998, you can skip all that stuff.
Wasn’t using web protocol the whole point of web services anyway? As Stefan said in his closing comments: “Protocol independence is a bug, not a feature.”
Use a RESTful architecture for new development. Put the web back in web services.
Microformats Introduction
I’m on record as being skeptical of the semantic web. Or rather, I’m skeptical of much of the marketing hype around the semantic web. That’s not to say that semantic technologies won’t be useful.
I still believe that both Resource Description Framework (RDF) and the Web Ontology Language (OWL) are too complicated to gain widespread adoption. But maybe we don’t need their academic rigor. Microformats offer a way to get some of the benefits of the semantic web using plain ol’ HTML.
What are microformats? How do they work? Emily Lewis wrote a great series of blog posts introducing microformats. You can also go direct to the source, the microformats homepage, at microformats.org.
An example
Here’s an example of our company address in hCard format.
The address above is marked up in such a way that (some) web browsers can identify it as a street address. But it’s nothing more than ordinary HTML. Here’s what the code looks like:
-
<div id="infovark_vcard" class="vcard">
-
<a class="url fn n" href="http://www.infovark.com"> <span class="given-name">Infovark</span>
-
<span class="additional-name"></span>
-
<span class="family-name"></span>
-
</a>
-
<div class="org">Infovark</div>
-
<a class="email" href="mailto:info@infovark.com">info@infovark.com</a>
-
<div class="adr">
-
<div class="street-address">10104 Bushman Dr.</div>
-
<span class="locality">Oakton</span>,
-
<span class="region">VA</span>,
-
<span class="postal-code">22124</span>
-
<span class="country-name">USA</span>
-
</div>
-
<div class="tel">800-833-9796</div>
-
</div>
It’s simple enough that it just might deliver where RDF and OWL fail, becoming part of every web developer’s toolkit.
Get started
You can experiment by creating your own hCards using the hCard creator.
And if you’re using Mozilla Firefox, you can download the Operator add-in to see — and use — microformatted data embedded in ordinary web pages.
Hat tip: Ajaxian for Getting Semantic with Mircoformats
