Tom Hollander's blog

patterns, practices and pontification

p&p in the Real World: First Impressions

p&p in the Real World: First Impressions

  • Comments 8

As a product manager at patterns & practices, I got to write a lot more code than most people would expect from a product manager. However the nature of the job and the team meant that it was basically all prototypes and samples. So after over 3 years, it's very exciting to be working as a solution architect in Microsoft's Solutions Development Centre where I am able to get my hands dirty with real enterprise projects again. And for the first time in ages, I get to experience something most of you do every day: finding out what it's like to use patterns & practices deliverables on "real world" projects.

Our team has just started work on a large customer project, and for the last two weeks my key task has been to establish the baseline architecture, which basically involves trying out design approaches and establishing repeatable patterns through implementing just a couple of use-cases end-to-end. So now I wanted to share how we are using patterns & practices deliverables on this project and what the experience feels like from outside of Building 5. Keep in mind that we are still in the early stages of this project and we may yet revisit any number of design decisions as we implement more features and get more test feedback - but hopefully these first impressions are still interesting, and I'll try to keep you updated on what changes as the project progresses.

I'm sure it will come as no surprise that we're making extensive use of patterns & practices deliverables on the project, although to be perfectly honest I didn't expect to be using so much at these early stages - it just happened that we kept running into requirements where they proved helpful. Here's a quick rundown of what we've used where in the baseline:

  • The baseline currently consists of two WCF-based services. The project structure and key service interface classes were generated using the Web Service Software Factory, and the overall architecture corresponds very closely to that described in the factory documentation. We didn't use the Service Factory to generate any of the data access components, since the SDC already has its own toolset for this purpose (in fact, the p&p Data Access Guidance Package was inspired by the SDC's solution)
  • Exception shielding is implemented at the service interface using the Enterprise Library WCF Exception Shielding Behaviour, which provides an entry point into the Exception Handling Application Block and Logging Application Block.
  • Cross-cutting concerns are able to be injected at the boundary of the business logic and resource access layers using the Enterprise Library Policy Injection Application Block. Handlers used at the business layer will likely include validation, instrumentation and authorisation. At the data access layer the key requirement is to map SQL Server error codes to .NET exceptions (see below)
  • The Enterprise Library Exception Handling Application Block is a nice solution for systematically wrapping or replacing one exception type with another - but it can't be used out-of-the-box to wrap a SqlException with different custom exceptions based on the included error code. To get around this, I used the Application Block Software Factory to create a new Exception Handler class that lets you configure different wrapping exception types for different error codes. I'll publish more details on this and share the code over the next few days.
  • The data access code (generated from the SDC's component generator) uses the Enterprise Library Data Access Application Block for managing database connections and calling stored procedures.
  • To save me writing about 5 lines of code, I used the Enterprise Library Cryptography Application Block for calling hashing algorithms without dealing with pesky byte arrays
  • Various aspects of the security model were inspired from guidance in the Web Services Security guide.

So that's what we've used. But what was the experience like? OK I realise I'm not entirely impartial, but here are a few thoughts from the first couple of weeks of work:

  • I'm only using any of this stuff because it works. As soon as it starts to cause more trouble than it solves it will be out the door. But so far, I've been very impressed by how much I've been able to achieve with so little custom code.
  • The Web Service Software Factory was awesome in setting up the initial layering for the services (although I do think some of the projects it generates could be merged together), and in most cases it saved me needing to hack configuration files by hand. However once I had the basic structure set up (with a very minimalist service contract) I found that I wasn't really using anything in the factory except for snippets to add new operations to the service contracts. While I'm very interested in where the team is going with the upcoming "modelling edition" of the factory, at this stage of the project I don't think having pretty DSL diagrams of my service contracts and service interactions will make my job any easier.
  • Even though I have always insisted that any Enterprise Library customers who want control over their own destiny should compile and strong-name the code themselves rather than rely on the pre-signed binaries, at this stage of the project I can't justify the effort to do this - although this may change.
  • The Policy Injection Application Block is way cool in keeping code clean and consistent. However a couple of times it's confused me by throwing meaningless NullReferenceExceptions when the blocks it uses aren't configured properly.
  • I was never a big fan of the Exception Handling Application Block, since it required writing a silly piece of boilerplate exception handling logic in every method. But with the Policy Injection Application Block and/or the WCF Exception Shielding Behaviour, this block is surprisingly useful :-)
  • When you create a new policy with the Exception Handling Application Block, the default post-handling action is NotifyRethrow, meaning the original exception will be returned back to the application. I've been stung by this about 4 times already, where I've configured policies that modify the exception, but the modified exception never gets thrown. If you don't change the post-handling action to ThrowNewException this won't work.
  • Given the choice of controlling block behaviour through configuration or attributes, I've been opting for the latter wherever possible (and unfortunately it's not possible all that often). I like being able to control things declaratively, but managing configuration files is already becoming painful - especially when you have multiple services and unit test projects, each with their own configuration files.
  • The Application Block Software Factory rocks! I built a new exception handler, complete with design-time, in about 3 hours. I would have no hope of doing this the old-fashioned way, even with generous copying-and-pasting from the Enterprise Library code base.

I'd be interested in hearing whether I'm still looking at p&p through rose-coloured glasses, and to hear how your experiences are different to mine. Also I know that Don, Grigori and the gang will be watching, so this is still a great forum to influence the direction that these deliverables go in the future.

  • Any chance we will be able to peek into code rather than your quite impressive description?

    Really like to see something because EDRA is getting 4 years old and so far no enterprise reference implementation is available using the .net 3 feature-map

  • Hi Adrian -

    I'm afraid that one of the differences between working on p&p projects and customer projects is that customer confidentiality means that I can't share the code. Still even if I could share it, at this stage it's way too early to position this solution as a blueprint for others to follow. Once the design has matured and has been adequately tested, I may be able to extract the interesting (and generic) elements into a new sample (or get the p&p team to do this).

    In the meantime, have you had a look at the p&p Software Factories, including the reference implementations? These deliverables are much more recent than EDRA and play a very similar role in demonstrating proven practices for end-to-end applications.

  • Tom,

    There's one big thing that sticks out in my mind.  Developer pain doesn't really hit until you are past the green field development part of the project.  I can cobble together nearly anything to produce a working v1 of an average sized project. Don't take my usage of the word "cobble" to make an implication on the P&P stuff.  By cobble, I mean nearly anything (non-OOP, half-baked in-house frameworks, etc).  Experience tells me these systems come together really fast for v1 (short time to market), but then the fit hits the shan after a large number of requirements changes.  v1 is really quick/cheap to build, v2 comes after many requirements changes and is either a complete rewrite or extremely expensive in terms of labor and debugging.  This has been my experience in consulting as I started out building a lot of half-baked applications. ;-)

    While I think it's very important that a team dogfood it's own work (and I applaud you for this), realize that the pain only shows itself down the road.

    Martin Fowler summed up my experience here:

    http://www.martinfowler.com/bliki/DesignStaminaHypothesis.html

    I would also be interested to hear the development methodology you guys are using (planning/testing/etc).  Tools are only a little piece of the battle.

    I do appreciate this post, and I look forward into getting a better peek into the MS world. :-)

  • Two things I've noticed...

    1.  The config problem never goes away and in fact keeps getting bigger and is harder to change later on.  I think it's a good policy to analyse your common bits of config and try to share them somehow.  This doesn't just mean sticking them in the machine.config though!

    2.  The comment about greenfield is true.  You may find that you have different views on some of this stuff when you enter perf test ;)

  • As I mentioned in my last post , I've been having some fun discovering what it's like to use patterns

  • As I mentioned in my last post , I've been having some fun discovering what it's like to use

  • MS Patterns and Practices to Become Test-Infected?

  • Well, I've had a blast using the data library.  I had a custom data class that was still a bit cumbersome to use, but man-o-man this new way for data access is awesome.  See, this is my first time using any p&p library and now I see what I've been missing.  Can't wait to utilize the exception class.  Thanks Tom and crew for such an awesome, quick solution developing apps.

Page 1 of 1 (8 items)