Architecture

My 11/6/2007 .NET Developers Group Presentation

Tim McCarthy — Wed, 07 Nov 2007 12:50:00 GMT

Here are the slides and here is the code from my presentation yesterday. Thanks to everyone who attended, I thoroughly I enjoyed discussing my upcoming book with you guys!

By the way, here is the link to my book on the Wiley web site:

http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470147563.html

I am writing a book on Domain-Driven Design

Tim McCarthy — Tue, 06 Mar 2007 23:07:00 GMT

I have been talking to people about this for a while, so I figured I’d blog about it too. Actually, I promised my friends over at the Domain-Driven Design Yahoo group that I would! The full title of the book is .NET Domain-Driven Design with C#: Problem-Design-Solution, and it will be published by Wiley Publishing, Inc.

The idea behind the book is that it will be a case-study book…a real-world application that uses Domain-Driven Design (DDD) concepts. After reading other bloggers’ posts, and hearing people ask for real-world examples on the DDD Yahoo group, I have decided to write a book that addresses this exact topic. The book is due to be completed at the end of the year, and will probably be out in early 2008.

My plan is to put some of the issues I run into on this blog and/or the DDD Yahoo group and see what other people have to say about their solutions to similar problems.

How to Create Custom Code Analysis Rules for VSTS 2005

Tim McCarthy — Tue, 13 Feb 2007 13:38:00 GMT

Building New Rules

The first step is to make sure there is not an already existing rule that is doing what you are trying to do!

Use the IK.CodeAnalysis.Rules solution to add new classes to the IK.CodeAnalysis.Rules project inside of the solution. Each new class will correspond to a new rule.

Add a new rule element to the Rules.xml file. Follow the examples from the rules that are already there.

Figure 1.1 Rules.xml file

All new classes must inherit from the BaseRule class. Make sure to add a private static class called “Constants” in the new Rule class. This is where the name of your rule as well as its resolution name will go. See the example rule classes in the project for reference.

Make sure that the Resolution element’s Name attribute is what you reference in the new Rule class as well as the Rule element’s TypeName attribute. These values should correspond to what both of the values are in the RuleName and ResolutionName constants in the private static Constants class of the new Rule. Feel free to put any other string literals into the Constants class.

Figure 1.2 The Constants class

Next, figure out what scope the new rule applies to; it may apply at several levels, such as Field, Property, Parameter, Method, etc. For whatever levels your rule applies, override the appropriate Visit methods from the BaseIntrospectionRule class.

The “Visit” Methods

The BaseRule class extends the BaseIntrospectionRule class, which in turn extends the StandardVisitor class. There are over 140 Visit methods that the StandardVisitor class calls during a rule check operation. What this means is that any Visit methods that are implemented in the new Rule class will be called by the rule framework. This is great because it allows rule developers to only focus on the parts of an assembly’s IL that they care about, such as all methods, or all private fields, etc. In order to trigger an error or warning to appear from a rule that has been broken, a call must be made to the BaseRule.AddProblem method.

In Figure 1.3, a call to AddProblem is made when a private field has been flagged as having a prefix in front of it.

Figure 1.3 An example of overriding the VisitField method

Debugging Rules

Follow the instructions outlined in #13 of the Resources section. In the IK.CodeAnalysis.Rules solution, there is a file named CommandLine.txt which contains a sample command line for debugging the custom rules in the solution. There is also an FxCop project file in the solution, fxcoptest.fxcop, which is necessary for debugging. In order to get debugging working, the rule developer will need to modify the paths referenced in both of these files to point to the correct locations on their machine. Once everything has been modified correctly, copy and paste the text from the CommandLine.txt file into a command-prompt window, and then run it.

Deploying Rules

In order to deploy the IK rules, the IK.CodeAnalysis.Rules.dll assembly file must be copied to the C:\Program Files\Microsoft Visual Studio 8\Team Tools\Static Analysis Tools\FxCop\Rules directory on each machine where the rules are to be run. That’s it, Visual Studio will load up and process all of the assemblies in this directory.

Suppressing Rules

There are some cases where it will be necessary to allow a rule violation in your code. A typical example might be a rule violation that is more of a design suggestion, instead of an actual violation, such as having a “GetXYZ” method that returns a certain type. This will result in a rule violation stating that the method be changed to a property, but you may have a very good reason to keep it as a method. In those types of cases the rules can be suppressed, but should be suppressed in code using the System.Diagnostics.CodeAnalysis.SuppressMessageAttribute attribute. Here is an example of what this looks like in code:

Figure 1.4 Suppressing a Rule

More information about this attribute can be found here.

Resources:

The very first resource any new rule developer should look at is #6 (Writing Custom FxCop Rules by Guy Smith-Ferrier) in the list below. This is a pdf version of a PowerPoint presentation that explains the process of building rules very well.

1. http://blogs.msdn.com/fxcop/archive/2006/11/16/faq-how-do-i-share-managed-code-analysis-rule-settings-over-multiple-projects-david-kean.aspx

2. http://blogs.msdn.com/fxcop/

3. http://www.gotdotnet.com/community/usersamples/default.aspx?ProductDropDownList=FxCop&SortDirection=Desc&SortColumnName=CreationDate

4. http://www.gotdotnet.com/team/fxcop/

5. http://blogs.msdn.com/fxcop/archive/2007/01/22/faq-what-exception-should-i-throw-instead-of-the-reserved-exceptions-found-by-donotraisereservedexceptiontypes.aspx

6. http://www.guysmithferrier.com/downloads/FxCop.pdf

7. http://davidkean.net/archive/2004/08/09/145.aspx

8. http://msdn.microsoft.com/msdnmag/issues/04/06/Bugslayer/

9. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1090172&SiteID=1

10. http://davidkean.net/articles/BaseRule.aspx

11. http://www.codeproject.com/cs/algorithms/Not_Used_Analysis.asp?df=100&forumid=332089&exp=0&select=1783417

12. http://dotnetjunkies.com/WebLog/tim.weaver/archive/2005/01/12/43651.aspx

13. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1090172&SiteID=1

A Composite Specification Pattern Implementation in .NET 2.0

Tim McCarthy — Mon, 22 Jan 2007 16:15:00 GMT

.NET 2.0 Composite Specification Pattern Implementation

According to Fowler and Evans, the idea of using Specifications is to separate the statement of how to match a candidate, from the candidate object that it is matched against. The main motivation pattern is to be able to select a list of objects from another list using various criteria in a very flexible, robust way. A nice side benefit of using Specifications is that they can be used for object validation/constraints as well as for building objects to order (like in a Factory). I was first introduced to this pattern from reading Eric Evans’ excellent book, Domain-Driven Design.

I have implemented the Specification pattern using the Composite pattern in order to provide the ability to combine Specifications in various ways. I really needed this in a project, and I was surprised that I could not find any .NET implementations out in the blogoshpere, so I went ahead and wrote my own, with a little help from Reflection and Generics.

Here is the basic diagram of the top-level classes:

For the AndSpecification and OrSpecification classes, they both take two ISpecification instances in their constructors, which represent the classes to be AND’ed or OR’ed together.

Here is a diagram of the Leaf-node classes of the Composite:

As you can see in this diagram, every Leaf is actually a Composite, which makes it very easy to combine Specifications. Below is a code example of how to combine specifications and use them:

///

///A test for IsSatisfiedBy (TCandidate)

///

[TestMethod()]

public void CustomerIsSatisfiedByEqualAndStartsWithTest()

{

TestCustomer candidate = new TestCustomer();

candidate.FirstName = "Tim";

candidate.LastName = "McCarthy";

bool expected = true;

bool actual = new EqualSpecification<TestCustomer,

string>("FirstName",

"Tim").And(new StartsWithSpecification<TestCustomer,

string>("LastName", "M")).IsSatisfiedBy(candidate);

Assert.AreEqual(expected, actual,

"The CompositeSpecification did not return the expected value.");

}

In this example, an EqualSpecification is combined with a StartsWithSpecification to perform two tests on the candidate object, which happens to be a TestCustomer type. The first test specifies that the FirstName property of the TestCustomer instance (the candidate) is equal to “Tim”. The second test specifies that the LastName property of the TestCustomer instance (the candidate) starts with the character “M”. The power of this is that the tests by themselves are very granular and easy to understand, yet also very easy to combine and execute, as evidenced by how the code sample combined two specifications on one line of code.

The code for the implementation (as well as a sample application) can be found here. Enjoy!

[5/22/2007: I moved the code for this project over to CodePlex. It can now be accessed here: http://www.codeplex.com/spec]

I definitely welcome any feedback on this code as well.

My talk on Domain Driven Design for the OC C#/VB.NET/Architecture User Groups

Tim McCarthy — Wed, 13 Dec 2006 08:51:00 GMT

First off, I have to say that I had a great audience, very intuitive and sharp! I am posting my slides and code again (even though I just gave this talk last week in San Diego) since I went through and added a bunch of stuff to it.

Here are my latest slides and code. As promised, in the code contains a full-blown .NET implementation of the Composite Specification pattern using .NET Generics.

Enjoy!

My talk on Domain Driven Design for San Diego .NET Developers Group

Tim McCarthy — Wed, 06 Dec 2006 11:34:00 GMT

That was a fun talk! Here are my slides and here is my code. As promised, here is a diagram of the latest DDD framework that I have developed:

Data types in .NET layered applications

Tim McCarthy — Sun, 13 Aug 2006 19:32:00 GMT

Recently I had a discussion with a developer at a client’s office about data types being returned from web services (and data passing strategies in layered applications), and in defense of my arguments I did some research. I ran across some interesting articles and they pointed out some stuff that I did not realize (or did not think about in certain contexts) about SOA and data types.

In actuality, the same thing gets passed back every time from a web service, which is an XML document that is defined by a schema from the WSDL.

I ran into a table (I took out the stuff which does not apply to us) which summarizes the data types and their pros/cons:

Abstraction	Contract standard	Advantages	Disadvantages
Text, JSON, binary	Informal, textual	Relatively efficient	Not self-describing, not ideally efficient
Native objects	Class definition	Unified behavior and data, encapsulation, high-level abstraction, and composition	Requires conversion of most data into objects, which requires a mapping technique
XML	XML schemas (XSD), Relax NG, WSDL, and many others	Self-describing, rich schema description, and extensible without breaking backward compatibility	Very size inefficient, no way to distribute behavior, and schema descriptions are limited even with XSD

In the case of a smart client, it will always be the XML type being passed from a web service to the smart client application. For the most part, I really like the pattern of the smart client talking to a generic service broker web service that accepts a variable number of arguments and returns a generic DataSet. Then once the client gets the DataSet (deserialized of course), it can do whatever it wants with it. That contract should never be broken, at least at design time it will not. What a DataSet does is it gives you a common abstraction to all data, which gives you a single unified model to work with. That is very appealing for all of the reasons that we discussed earlier.

What could happen once the application receives the DataSet is that you may try converting the DataSet to some type of strongly-typed DataSet (based on a schema) or a class instance on the client at run time, and that is that part that could break. This is what I like about the DTO pattern, everything is strongly typed at design-time, and type-casting errors are caught by the compiler and not the run-time.

DataSets are nice in .NET consumers because the framework will automatically convert the XML from the web service into a DataSet (not just the data, but all of the DataSet functionality) “automagically” for you, whereas it will only convert a class entity into a dumb object (just with properties only). Now, you could modify the proxy to convert the XML from the web service to cast it to a local class instance (or better yet use a derivation of the Mapper or Assembler pattern), but then you would need the definition of the class to be referenced (either in a .cs file or in a referenced assembly) on the client, but with a DataSet this happens for free (you get both the data and the behavior).

One thing I also found out was that you can have a web service that has nullable data type arguments, meaning that you can actually change the contract of a web service without breaking an existing consumer of the service (although they will want to eventually upgrade). In XSD terms, this means that all non-essential arguments can have their nillable attribute set to true (nillable=”true”).

Anyways, I’m glad we talked about it because it really got me thinking bout this stuff.

By the way, all of the articles that I read in regard to this subject were in this month’s edition of The Architecture Journal (Issue 8), which you can get to at http://www.ArchitectureJournal.net. Luckily, I just happened to have a hard copy with me in my backpack while travelling back home, and this month’s theme was Data by Design.

The Layered Architecture Domain Model

Tim McCarthy — Thu, 02 Jun 2005 03:23:00 GMT

I've recently been working on a project at a client site where they are in the process re-building all of their applications from legacy systems onto the .NET platform. Talk about a architect's/developer's dream!

Some of the things that we decided for the general architecture of these applications were:

1. We were going to use a layered domain model for the overall object model type of all of the applications.

2. We decided that we were going to use Data Transfer Objects (DTO's) to pass the data around to the various layers. According to Martin Fowler, a DTO is “an object that carries data between processes in order to reduce the number of method calls“. In our .NET implementation, the DTO's are just classes with properties and no methods associated with them. They can be used by any layer in the application architecture, and thus get placed into a common assembly. No DataSets or Readers being passed around, just classes.

3. We created a separate business services layer, as well as a separate data services layer. Both layers use the DTO's. The data services layer uses the Microsoft Data Access Application Block (DAAB) to access stored procedures in the database.

Here is what the architecture looks like, from a component perspective:

I am tired and need sleep...I will post more on this later.