Monday, July 28, 2008

Vista Update Whacked My Video Driver (Not)

Lost the weekend thinking I'd blown up my XPS video chip.

Update: It was nVIdia chip after all! Everything I said below ... all the wildly varying advice on the web and from our in-house tech ... was for naught. In fact (as some reported) the nVidia chip slowly fried into digital mush.

Lucky for me, Dell replaced the motherboard (at last that 3 year service agreement pays off!) and haven't seen any problems since. A BIOS update that turns on the fan at lower temperatures was also part of the deal. My XPS isn't as quiet any more but she's running!

I leave the completely false information below as a sign of the abounding misinformation. Do not be fooled and waste hours thinking you can fix this yourself or blame Microsoft.

--- The following is false ---

Turns out Windows Update automatically replaced my Vista nVidia driver with something Microsoft recommended. Their replacement driver behaved in ways that looked like hardware failure to me. Rolling back the driver didn't help which made me "sure of it".

I'm way out of my league with this stuff. Thank goodness we have someone on staff who could figure it out. The clue that it wasn't hardware is that everything worked fine (if ugly) running with just VGA drivers. Like I know how to do that? No way. But my guru did. Found the correct drivers on Dell's site and reinstalled them.

I don't know how the "normal" world copes with this stuff. One minute everything is fine. Next minute (after a Windows Update that you didn't even remember seeing), your laptop is failing with bizarre video artifacts, driver reboots, freezes ... and you're weeping like a baby.

Lessons Learned:

  • Don't let Windows update your machine without your explicit agreement
  • Don't download the optional stuff
  • Examine the proposed updates carefully and choose the ones you "know" to be safe. My guru advises that I stick to the security updates only.

Good luck!

Monday, July 14, 2008

DDD is for CRUD Apps

I wrote this piece for the Entity Framework Wiki where rage a number of folks with contrasting degrees of affection for and animosity toward Entity Framework. Maybe some of you will see it here first. :-)

When confronted with a brown-field application development scenario I often find myself in the camp that finds value in leveraging an existing database schema during the development of my domain model. By "leveraging" I mean that I construct some part of my domain model with the aid of an ORM tool that takes the database schema as one of its inputs and produces a conceptual model as one of its outputs. I am pleased to use that conceptual model to generate a portion of my domain model.

For some this approach is anathema. One expression of revulsion is to dismiss the tool and approach as suitable only for CRUD applications. Apparently a CRUD app is pretty low on the sophistication scale. I am often told that if this is "all" I'm going to do (read: all that I am capable of), I should stick to one of the less intellectually challenging design patterns, maybe ACTIVE RECORD, and leave OBJECT MAPPER and DOMAIN MODEL to the big thinkers.

It follows also, they would suggest, that this so-called "Data First" approach betrays an almost constitutional ignorance of modern design patterns and practices and is utterly incompatible with Domain Driven Design (DDD). I think this leap to judgment, while understandable, is unwarranted and prematurely terminates what could be productive discussions.

In this page I will hold that

  • DDD is almost invariably demonstrated with a CRUD application
  • Data-firsters build behavior rich Domain Models too
  • Ease of code generation undermines thought
  • The real question is "do you engage your design faculties or not?"
  • Data-first can assist DDD
  • DDD and "Data First" are compatible when the "Data Firster" uses his or her head

DDD for CRUD

Jimmy Nilsson shows us DDD in action in his highly regarded book, Applying Domain-Driven Design and Patterns [ADDP] by stepping through the design and development process of an application with the following requirements:

  1. List customers by applying a flexible and complex filter
  2. List the orders when looking at a specific customer
  3. An order can have many different lines
  4. Concurrency conflict detection is important
  5. A customer may not owe us more than a certain amount of money
  6. An order may not have a total value greater than a predetermined system-wide order limit
  7. Each order and customer should have a unique and user-friendly number
  8. A new customer is acceptable only after passing a credit check by an independent institution
  9. An order must have a customer; an order line must have an order
  10. Saving an order and its lines should be atomic
  11. Orders have an acceptance status that is changed by the user

This is a classic CRUD application. It is, in words typically uttered with total derision, "just a CRUD app."

It is also the richest investigation of DDD development that I have found. Jimmy devotes nearly half of the 500 pages of his book to this example. I have yet to see an example of DDD in practice that is as thorough as this one.

This is the only example in Jimmy's. He never even hints that this CRUD app is inadequate to the task of demonstrating DDD. It is all he requires to show DDD's superiority relative to the way he used to build applications. Yes, the app is a toy and half-baked - as it must be for purposes of exposition. But it does what he wants it to do pedagogically.

I'm not trying to make Jimmy a saint or sinner. This post is not about Jimmy.

I do intend to make it hard for someone to say, "well, that's just a CRUD example and DDD is for more sophisticated applications." I figure if Jimmy wrote the app with DDD, it's a DDD app. If Jimmy thought we should use ACTIVE RECORD instead of Domain Model, he would say so.

I am also trying to discover if there is something distinctly different about applications that people are building with DDD. On the strength of this example, we all seem to be building the same kind of apps.

Are so-called "object first" applications somehow beyond the reach of applications developed when you use "data first" techniques? Is there something Jimmy is doing here that we aren't doing routinely ourselves? Not that I can tell.

We Build Behavior Rich Domain Models Too

A subset of Jimmy's application's requirements are manifestly "behavioral"

  • Concurrency conflict detection is important
  • A customer may not owe us more than a certain amount of money
  • An order may not have a total value greater than a predetermined system-wide order limit
  • Each order and customer should have a unique and user-friendly number
  • A new customer is acceptable only after passing a credit check by an independent institution
  • Saving an order and its lines should be atomic
  • Orders have an acceptance status that is changed by the user

Guess what? You will find implementations for such requirement in my "data first" applications. These kinds of requirements are routine for us as well.

Look closer at my own applications and you will see Aggregates, Value Objects, Services, Repositories, Unit-of-Work, inheritance, etc.. You'll see Dependency Injection and MVC/MVP too. I can't say that I have always been as clear and decisive with the purely DDD structures; I'm new to the DDD formalisms although one of the reasons it resonates so strongly with me is that (as with the GoF patterns) there is a shock of recognition when you first seem them - the realization that DDD captures what you should have been doing - and were sort of doing - all along.

It certainly seems to me that I approach these needs with the same attitude and catalog of "solutions" as any "object-first" architect. I just happened to get there with my "data-first" tools. And I didn't have to stand on my head or otherwise fight my own tools or predilections to do so.

Let's take "behavior" for example. Someone is always trying to tell me that "data firsters" don't understand the difference between data objects and objects with behavior.

There is some strange misconception, widely repeated, that "data firster" business objects lack behavior; that they are just stupid property bags straight from the ORM code generator. Where does this notion come from? Every generated domain object class file is paired with a custom class file. That's where we put our behaviors. We are going to enrich our domain model in order to satisfy the expectations coming from the business and we're going to do it in that custom class. Go ahead and decry the noise and alleged confusion that I must be experiencing because I have two class files to do the work of your single file (psst - I hardly notice). But why insist that I'm not writing behavior at all?

When I look at Jimmy's classes - the ones he actually wrote - I don't see any important differences between what his code does and what my code does. You will find no less behavior in one of my business object classes than in one of Jimmy's classes.

Yes there are differences - we won't write the same code. But once you set aside the code gen and Persistence Awareness artifacts, what is left of genuine substance to fight about?

I must be quick to acknowledge that there are characteristic misbehaviors with the "data-first", code-generation approach that always show up in the code. Every technique is prone to its "signature" mistakes - the kinds of mistakes that are so easy to make that they always leave evidence behind. We'll talk about some of these shortly. But they are minor sins, easily expiated.

My point, in this section, is that, from the perspective of a consumer of the Domain Model, there is no fundamental reason for Data-firsters to produce a domain model that is appreciably different from the one produced by an Object-firster.

There are some differences in how we got to a given place. There are some differences in how we pursue development in subsequent iterations. But if we both consistently produce a domain model that delivers the same capabilities, with similar APIs, in a similar amount of time, with comparable quality, ... iteration after iteration ... then I cannot see why one camp must lord it over the other.

The burden of proof falls on he who would claim that we cannot achieve comparable outcomes.

What About Those Getters and Setters?

There is a faction within the DDD family that is at war with getters and setters in Domain Model classes. I think they make important points. I also think they over-state the benefits and understate the challenges of doing without getters and setters. Challenges begin in earnest when you have to present domain objects in the UI. If we are to move state between a domain object and widgets on the screens, with today's client technologies one is driven to writing intermediaries (e.g., DTOs) that actually do have properties . For a glimpse of the tedious care and feeding such intermediaries require, see Mats Helander's article in Jimmy's book [p.431]

Aside: this has nothing to do with separated presentation per se. If domain model objects are property-less, the "Model" -  in MVC or MVP or embedded in a Presentation Model - can not consist of domain model objects; there must be intermediaries. Perhaps this is a virtue but it is won at hard cost.

If you believe getters and setters are bad, you will really hate the "data-first" ORM approach which emits properties in great abundance. Property generation is the strength of the "data-first" style. It is its strength ... and its weakness.

Before I pursue that thought, I must observe that the "no properties" faction appears to be a minority within DDD. Maybe Jimmy's example application is "old-school" DDD - it's so "2006" - but his domain model classes have plenty of properties and his associates, who build the UI on his domain models, are not shy about working directly with those domain objects and their properties. So I don't think DDD'ers are united in hating properties.

But the property resisters have a great point. DDD stresses the importance of designing and implementing in the language - the ubiquitous language (UL) - of the business domain. If "Get LastName" and "Change LastName" are sensible operations in the UL, the properties belong. But if "ShoeSize" is not a meaningful fact about a person in the UL, we should not have a ShoeSize property.

Data-firsters have the bad habit of acting as if every column in every table is directly expressible in the UL as a "get" and "set" operation. In other words, we have a tendency to expose every column as a property. It's just so easy to do.

The same is true for bi-directional relationships. Order.Customer? Customer.Orders? The ORM can generate them both; let 'er rip.

Again, it's so easy ... that we let the ORM generate these properties ... and now our domain model has unwanted behavior that clouds our vision, adds a point of failure, and consumes testing resources.

There is something insidious in this too. Our ubiquitous language may support setting the Last Name. But not necessarily at will. Not necessarily in isolation from other domain model state or rules. By blithely spitting out a LastName property, we gloss over the careful analysis that should have gone into the decision to expose a mutator of this value.

Do You Design Or Not

Let me stipulate: blind "data-first" thinking combined with rapid code generation is a formula for poor design.

I know the perverse delight in spewing a "model" of 100 table-backed-classes in fifteen minutes. I suppose this is like firing off a few thousand rounds from an assault rifle. Kind of cool on the range; not very cool if I do the same thing at ... I don't know, let's pick on the poor post office again.

Is it the tool's fault? Or is it my fault?

If I use the ORM this way, shame on me. I didn't have to.

I may have to cope with the fact that the legacy ShoeSize column is in my Person table ... and I am not allowed to get rid of it. But I don't have to expose ShoeSize publicly as a property. I don't have to expose both sides of a relation. And, if there is special business logic governing how to change LastName, I can bury the property and write a "message" method to mutate it properly.

In short, if I just fire up the ORM and pull the trigger, does my tool make me an idiot? Or am I an idiot to begin with.

When Data-First Improves Design

A significant portion of Evans seminal DDD book concerns how you determine what the domain model should be; how you align it with the business. The message, repeated in many forms, is "this is very hard."

If you've been a consultant, you know that learning your customer's requirements is wickedly difficult both because she isn't sure what she wants and because you don't understand her business well enough to understand her even if she explained it well.

You have to play anthropologist. An apologist listens to stories, yes, but he also looks at actual behavior and, in particular, the artifacts of the culture he studies.

I suggest that an existing database is one of your most important sources of insight into the culture. That database didn't happen by accident. ShoeSize is in there because someone went to the trouble of putting it there. Just because your client didn't mention ShoeSize once during your interviews doesn't mean you can ignore it. Even if she says "we never use that", the experienced consultant retains the nagging suspicion that something important is missing ... and won't rest until the mystery of ShoeSize is resolved.

We used to say, "show me your data and I'll tell you what your application does." Flippant perhaps, but not altogether wrong.

I almost forgot this maxim because it seemed so obvious. Yet I can't remember it being mentioned in a single DDD book or article. I think you're missing an important design opportunity when you neglect to start from the existing data schema.

Conclusion: DDD is for Data-Firsters too

DDD is first and foremost about studiously matching the domain model to its business purpose. That's hard work. Data-Firsters cannot escape that work - even if running the ORM on auto-pilot seems at first to deliver good results. The schema is only one of the inputs to the ORM; our judgement - what tables and columns to model, how to expose columns or relationships as properties, what data should appear as Value Objects, etc. - is the more important input.

Of course domain model objects have behavior. Data-firsters are not satisfied with property-bag classes. They add behavior as they go ... just as Object-firsters do.

DDD describes structures and design patterns that favor an evolutionary domain model that serves the business. We sometime data-firsters build those same structures and follow those same patterns.

Unit testing is critical to the iterative process promoted by DDD. Our persistence infrastructures must facilitate unit testing. In particular, we must be able to test the model without connecting to a database. Some persistence infrastructures just missed this boat. Big mistake. Unfortunately, many of these infrastructures - I'm thinking of Entity Framework in particular - are associated with tools favored by data-firsters.

I'm going to claim that this is a spurious correlation. There is nothing about the data-first approach that requires an infrastructure that makes testing hard. A persistence aware infrastructure does not have to make unit testing hard. That many do is a correctable error. 

DDD emphasizes the importance of reducing friction in facilitating continual redesign and re-implementation. Friction discourages us from seeing and making the changes that improve the model. Our code-generating ORM tools undoubtedly introduce some friction into the process. The need to regenerate the domain model simply to change a persisted property's name or accessibility is among the more glaring examples of friction.

But I think it's also time for the object-firsters to come clean about the friction they introduce. The friction is not always in the domain model; it pops up elsewhere in the system because of what is not in the domain model classes. Jimmy's book is pretty fair in its recital of the ugliness in the "infrastructure ignorant" discipline. The "no properties" school introduces another, huge source of friction to the process - whatever the compensating benefits.

But I digress. The point I want to make is that, if data-firsters tame their unbridled exhuberance for their tools and use them wisely, they too can practice DDD.

Then we can all build CRUD apps ... of any sophistication.

Friday, July 11, 2008

I talk with Jeremy Miller about ORM

Mike Moore of Alt.NET Podcasts arranged and captured a conversation between Jeremy Miller and me about Object Relational Mapping (ORM) and persistence frameworks. You'll find it here.

Jeremy is one smart guy and he has the industry experience that gives depth to his intelligence. He cares passionately about the craft. He has a fine sense for the balance between the principle and the practical. He's a gifted speaker and writer and, fortunately for us, he does a lot of both.

He also signed the Entity Framework "Vote of No Confidence", a document I began to criticize in an earlier post. We have contrasting views about what makes a good ORM and we explore some of the particulars in this conversation.

I think we did a number of things well. It was not a "smack down" or any of that kind of nonsense. We find much common ground. We jointly articulate the benefits of ORM as we see them.

And we retain that camaraderie even as we explore our differences. We go beyond the doctrinaire recital of our respective catechisms to discover what we each think matters most. As I review the tape, it seems to me that we share the same fundamental concerns; we just react differently to the pain and trouble you'll encounter when you follow one route or the other.

I don't believe either of us was persuaded to change sides. I don't believe there was a "winner" nor was that the intent.

I do believe we each found merit in the other's position and remained open to challenging our own most fondly held views.

I hope you'll give it a listen.

Kudos to Mike for producing a lively and balanced show.

Wednesday, July 2, 2008

Composite Application Guidance (CAG) for WPF is here!

Patterns and Practices just released the Composite Application Guidance (CAG) for WPF 2008.

You might know it by its codename, "Prism" ... a name I loved and will miss. What matters is that it exists. There is now a set of libraries and guidance for building WPF applications in a compositional manner.

Why does this matter? Because most of us have learned the hard way that we should "compose" our applications from parts and pieces. The question is not should we do so, but how to do so.

How do we build those parts independently and make them come together in what the user perceives as a single application? It's easy if the parts have nothing to do with each other. It's much harder if the parts must interact. We're going to need some architecture, some patterns, and some glue code to achieve that blissful state in which truly independent components, with no references to each other, somehow manage to collaborate seamlessly.

Patterns and Practices has been down this road before with the Composite UI Application Block (CAB) and its add-ons (Smart Client Software Factory, Web Client Software Factory, etc.). CAB was PnP's pioneering effort in this space. It achieved considerable success; there were many substantial applications built with CAB and my company wrote its own application integration layer on top of it called Cabana.

It also acquired substantial notoriety. Everyone agrees it had too many moving pieces that were hopelessly entangled and that it was devilishly difficult to learn.

So when the team took up the challenge of providing compositional guidance for WPF applications, they seized the opportunity to re-examine the CAB experience, harvest what worked, and improve upon its defects.

They reached out to the developer community, drawing upon those with CAB experience and upon those who had experience with rival approaches. And they listened. And they spiked what they heard and listened some more. They turned the spikes into production code and listened again. Iteration after iteration.

The Results

They have delivered an elegant product. On time. Far ahead of the December '08 date that I dreamed of in my unbridled optimism.

I think it hits the right notes. CAG is small enough to understand and rich enough to support serious application scenarios. The parts work well together. But you don't have to use them all and you can easily substitute your service for any of the shipped services.

The team likes to talk about how you can replace the Dependency Injection mechanism with your favorite: Unity, Castle, StructureMap, etc. I think it is as important that you can replace the EventAggregator or RegionManager or any other ingredient that didn't suit your needs. Not that I'm in a hurry to do so. I just want the comfort of knowing that I could.

This time PnP devoted serious effort and resources to guidance. You see it most prominently in the "Stock Trader Reference Implementation" (RI) that demonstrates (a) what we mean by a "compositional UI" and (b) how all of CAG collectively supports such an application. It is simple without being simple-minded. It's a toy for sure but it serves its pedagogical purpose well.

  Note: Please don't build on it! It is not an application framework. Its practices are not always the "best" or even necessarily good. It is a resource for you; a place to discover how you might solve a problem with two or more CAG components in combination.

I don't know for sure but it sure strikes me that CAB's RI, the "Bank Teller", was an afterthought. Not so with CAG's "Stock Trader". It was designed first, before CAG work began in earnest. It co-evolved with CAG. It is and was intended to be CAG's "acceptance test".

There are eight "Quick Starts" that explore CAG components individually and (mostly) in isolation. As with the RI, you wouldn't slavishly adopt Quick Start code. Indeed, you should probably fight with this code, hurl it against the wall, and shake your fist ... and after your satisfying tantrum subsides, you will realize that you understand how it works. Somewhere, someone on the PnP team will be smiling.

There are over 300 pages of CAG documentation. This is not of the "insert tab 'A' into slot 'B'" variety. The team tried to explain "why" as well as "how" and it shows.

Is CAG right for you?

How would I know? I haven't built anything with it yet. And I don't know anything about you. That won't stop me from telling you what to do.

I would use CAG if I was starting a new WPF project. I'm convinced it will pay dividends immediately. WPF applications, more than Windows Forms applications, resist compositional strategies. I'd want to work on manageability early. WPF itself is still a struggle to learn and when things go wrong, they go really wrong. I want confidence that if this little corner of the application catches fire, the rest of my house is well insulated and will keep standing.

There is no CAG for Windows Forms or Web Client. If I had an existing CAB investment, I'd stay with it. If you are starting a new Windows Forms project and have some time to kill, you might glom on to one of the efforts to port CAG to WinForms ... there is sure to be someone attempting it soon. I say this as a CAB guy too. I would be sorely tempted to develop in CAG rather than CAB if I was starting a new WinForms app and had enough lee-way to make some beginner mistakes. It's simply that much better than CAB, even in the medium term.

If you have a CAB app today, do not despair. Don't be distracted. Don't drop everything and re-implement in CAG. CAB is working for you. Sit this one out until there is more real world CAG experience.

If you're building your application in Silverlight ... you're getting ahead of yourself aren't you.  Expect to see a CAG for Silverlight. Someone is bound to port it. I just don't know who.

The Best WPF Business App You'll See This Year

I just watched a DotNetRocksTV video of the application that Billy Hollis demo’d at Tech Ed 2008.

Far and away the most effective demonstration of WPF for a Line-of-Business (LOB) app that I’ve seen. You will never mistake it for a Windows Forms knock-off. I  look at this app and I say:

“THIS is how WPF can be a force for greater user productivity.”

Chock full of “aha” moments. Check out the tasteful use of color, typography, and animation. You'll be amazed by the humble ListControl. The only thing I feel I'm missing is sound.

He isn’t using anything complex or incomprehensible. All techniques rest on foundations you will find in all of the books. Except Billy has put them to good use. He and his team are laying down patterns that should encourage us and inspire us.

It’s a short, feature packed video and worth the 20 minutes of your time it will take to watch (assuming you skip the commercials).

This is the future of user experience. Ok ... I'm gushing ... but it's still great.

Tuesday, July 1, 2008

Big Silverlight Troubles! No synchronous server calls

We have been tearing our hair out around here because we can’t find a way in Silverlight 2.0 Beta to write a method that blocks the UI thread while it fetches data.

In case you are not aware of this problem, permit me to illustrate.

Suppose in the bowels of your business logic you have a validation rule that says: “total of order not to exceed the customer’s maximum cost for a single order”.

You’re using a domain model with objects that have dotted navigation. You write your rule along the lines of:

… TotalCost(myOrder.Details) < myOrder.Customer.SingleOrderLimit …

Unfortunately, both myOrder.Details and myOrder.Customer.SingleOrderLimit could involve lazy loads of the Details and the Customer.

The UI that enabled the user to create a new detail item for the order is not aware of this rule and didn’t pre-fetch Details and/or SingleOrderLimit.

No problem in regular .NET. You just wait while you lazy load the SingleOrderLimit from the database.

Big problem in Silverlight.

All server calls have to be asynchronous. Your fetch of the SingleOrderLimit is going to have to return immediately; the value will be accessible later during the asynch callback.

Ok, you try to rewrite SingleOrderLimit to stall the UI thread until you get the callback. But there’s no way to do it. If you sleep the thread, you never hear the callback. You make the server call on a worker thread and sleep the UI thread; you never hear the callback. Sit and spin on the UI thread? You never hear the callback. What’s with that?

I understand that I can write synchronous code on the background thread. The problem is that I can't make the UI thread wait for the result.

So you try to live within this crazy world. You decide that you will somehow detect this particular problem and you stash the validation object somewhere, postponing its execution until all the dependent server trips have completed; in my example, the validator can’t run until Details and Customer have been retrieved and how I knew to stack these dependencies is anyone's guess. Good thing they're mutually independent requests because if one query depended on the outcome of another query, the logic would get really twisted.

Meanwhile your original validation call - the one that got us into this mess - must return with some indication like “I don’t know”.

It can't report “everything is ok” or “it’s invalid”. So you have to be sure that the ancestor caller somewhere way up the stack postpones whatever it was doing (like trying to save the order) until you have a definitive answer. And, of course, when it becomes possible to render an answer, you have to remember to renew your originating operation (e.g., the save). You weren't just going to tell the user "Sorry, I can't save yet, not enough information ... try again soon" were you?

Let's say you got that all figured out. But watch out. Maybe your WPF-ish UI is binding to objects in your unit-of-work container. Over on your worker thread you're doing some synchronous magic that fetches Customer and Detail objects. You better not put them into that container on the UI thread ... because it's not thread-safe and if WPF is looking for 'em there's going to be trouble! You better be ready to fetch Customer and Detail into a separate container and then martial them back across the thread boundary in the callback. Oh joy.

You see where I’m going with this. Application programming just became immensely difficult. You can’t write a real program if every data fetch is async. Your UI controller shouldn't have to anticipate every bit of data you might possibly need upfront either. This is a disaster.

Do you know what to do about this? Do you know anyone who does? We’re beating every bush and so far, nada.