Creating a virtual property code snippet

Hi,

For those of you who use NHibernate, you must know by now that NHibernate forces us to declare our entity’s methods and properties as virtual since it uses proxies to implement lazy load of relations.

I created a small code snippet called vprop – same as prop only virtual.

It looks likes this:

<?xml version="1.0" encoding="utf-8" ?>

<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">

    <CodeSnippet Format="1.0.0">

        <Header>

            <Title>vprop</Title>

            <Shortcut>vprop</Shortcut>

            <Description>Code snippet for an automatically virtual implemented property

Language Version: C# 3.0 or higher</Description>

            <Author>matang</Author>

            <SnippetTypes>

                <SnippetType>Expansion</SnippetType>

            </SnippetTypes>

        </Header>

        <Snippet>

            <Declarations>

                <Literal>

                    <ID>type</ID>

                    <ToolTip>Property type</ToolTip>

                    <Default>int</Default>

                </Literal>

                <Literal>

                    <ID>property</ID>

                    <ToolTip>Property name</ToolTip>

                    <Default>MyProperty</Default>

                </Literal>

            </Declarations>

            <Code Language="csharp"><![CDATA[public virtual $type$ $property$ { get; set; }$end$]]>

            </Code>

        </Snippet>

    </CodeSnippet>

</CodeSnippets>

Just make sure to save this xml to:

…\Visual Studio 2010\Code Snippets\Visual C#\My Code Snippets\vprop.snippet

And typing “vprop” followed by two Tabs will generate a virtual property.

Enjoy!

NHibernate Tutorial, Part 1 – Introduction

Hi everyone,

I’ve been working with NHibernate for almost two years now, and it’s been a pretty fun ride. Since I’ve learned a lot along the way I thought I should provide an NHibernate tutorial, specifically working with spatial entities since I don’t think there’s enough material out there on that topic.

Now, there’s a LOT of knowledge and good NHibernate tutorials there so I’ll try to give a link to another article where I see fit, starting with:

1. A screencast tutorial from summer of NHibernate, for a more visual tutorial. I can’t say I’ve seen it since I’m more of a reading kind of guy, but I got the impression it’s good.
2. NHibernate 3 Cookbook – a great book that that introduces real life NHibernate usages and tools.
3. Oren Eini’s (AKA Ayende Rahien) blog – One of NHibernates contributors and the writer of a great software design blog.

I’ll also combine Domain Driven Design principles along with this tutorial, as we develop our own application. Let’s go.

Some History…

Let’s look at a simple example:

Ignore the base class IntEntity for now, we’ll get to it later – just keep in mind that each of the above entities also has an Id property and a version property, both of type int.

Now, a single Store has many Branches, and a branch has a reference to it’s parent store. Also, each store has a reference to a Person who’s it’s contact, and each Branch has a person who’s it’s manager. A simple model in OO, but a bit more complex in a relational database:

A property becomes a foreign key and we have a One-to-Many relationships – it’s up to us to make the conversion back and forth to objects. Now, we want our application to persist these entities while keeping the entities oblivious of the underlying mechanism.

If you’ve ever worked with ADO.Net or any other DAO framework, you know it means a lot of implementation (even if we auto-generate some code) – each entity has it’s own SQL queries for CRUD operations that requires manual implementation and maintenance, not to talk about inheritance modeling. Also, it doesn’t’ support refactoring since it’s based on pure SQL strings.

Oh, and did I mention we want the same entities to be persisted on Oracle10 and Sql Server 2008, and tested against Sqlite?

NHibernate to the rescue!

NHibernate is a mature, open source OR/M framework, which basically means it allows us to model our entities naturally as objects, and define how they should be be to the underlying RDBMS in a more declarative way. It was originally ported from Java’s Hibernate thought it has a life of it’s own for some time now.

Microsoft also provides an OR/M framework called Entity Framework, it’s not as mature but it’s growing fast and it has a great designer support, if that’s your cup of tea. Still, NHibernate is more mature and supports more features.

To start working with NHibernate, we need to map our model, configure our database connection and settings and actually use them in our application.

We’ll continue on the next part - Modeling Our Domain.

Entities vs. Value Objects

As I mentioned in a previous post,  our application would consist of multiple layers, one of which is the model layer – services, factories, entities and repositories (*cough* session? *cough*).

But what do we mean when we say entity? or more precisely, how do we identify our entities, and what’s the best way to manage them and express the rest of the data? Let’s start be defining entities and value objects:

Entities

An Entity is an object that’s defined uniquely by an identity, we’ll usually persist those objects and they’ll contain both data and behaviors. They are the core of our domain, and require careful and well-thought out design – what one application may refer to as a User is probably not what another system will. Entities will probably contain references to other entities and value objects, but more on that when we talk about aggregates.

As a best practice, entities should focus on their domain’s business logic and be ignorant to their infrastructural concerns, such as database persistence. That’s where OR/M frameworks come in handy, helping us keep our entity a POCO (or POJO in the Java world), unlike other approaches such as Active Records which delegates the entity with the persistence responsibility.

Value Objects

On the other hand, Value Objects are not being tracked and are not uniquely identified. The most common example is the address object – It has a few properties that together represents a conceptual whole but it has no identity. Keep in mind that your domain may use addresses as entities if they need to be tracked uniquely – a billing address of a customer is probably a value object while in the real-estate domain it could be a uniquely identified estate. Value objects van contain references to other entities and value objects, though probably not as frequently as entities.

As a best practice, value objects should be immutable and cheap to create. Immutable objects are by definition objects that don’t change their value after creation, such as String or DateTime. For more on that, go here.

Often, value objects will contain either data only (also referred to as a Data Transfer Object, DTO) or behavior only.

Summary

Entities are objects that have an identity by which they can be tracked, they are the core of our domain and should be designed as precisely as possible with help from our domain expert. Value objects are objects that help us express a conceptual whole in a reusable way, they should be cheap to create and immutable.

UX is everywhere!

I overheard a conversation today about gas stations and it made me think about why I keep filling gas at same company for the last couple of years. As a bike owner I don't really feel the rising prices of gas so my main consideration isn't money - what then makes me come back?

Oddly enough, the reason is User Experience. You see, I don't like to move my fat buttocks more than I have to, that's why I prefer using a credit card – I don't even need to get off of the bike thanks to the gas station's self-service user terminal. Yey.

The only thing I do need to do is enter my ID number and license plate number. While my ID number is obviously critical when paying with a credit card, the license plate should be optional since it's up to me to limit my card to specific vehicles, right? Well, most gas station companies don't think so since it's a required field! I bet it means nothing for most users… (either that, or I'm the proud owner of a vehicle licensed 11-111-11 for some time now).

My favorite gas station company is different because the terminal's user interface instructs me to enter my license plate number or press 'Enter' to continue. Silly as it may be, they get my money – others don't.

When designing a good UI don't make the user think – make him experience. Try to make that extra step forward in figuring out what he may want at any point, without clutter and noise. Definitely not an easy task, but if you won't take it somebody else will – and that might be a good enough reason to choose a competing product.

Introduction to Domain Driven Design

I’ll try to explain what DDD is all about in a nutshell as explained more broadly in this great free online pdf (a must read for every system architect IMHO), which in itself is a nutshell of this (so I‘ve heard) great book about DDD. It also includes other topics I figured I should add. If you find yourself dozing off while reading, feel free to jump straight to the Summary for a quick reference. Put yo’ helmets on.

What, Why and How?

Let’s start with a confusing diagram that sums it all up, yet means nothing at this point:

Confused? Let’s try and put some sense into it.

Developing a business application is all about increasing that business’ productivity by solving a real-world problem or automating a real-world business process, either way we’re dealing with a real-world Domain of entities, data and processes.

Domain Driven Design is in it’s core an approach to software design, which emphasizes the need to focus on the business domain in which the software operates, and model our software as a reflection of the real world. Why? because software is eventually made up of code, and the bigger the problem you’re trying to solve the more complex and messy it can get. Staying true to the “real world” keeps our software understandable, cohesive, easy to change in respect to the target domain and most importantly – do what we expect it to do, as it imitates reality. OO languages are best for this design method since they allow us to define entities and processes in an intuitive, language natural way.

Now, while the development team consists of experts in many technical areas, they are usually not experts in the business domain. Since you can’t produce a good solution to a problem you don’t fully understand we can conclude that In order to produce good quality software you must involve an expert of the business domain in the development process. (On a side note, agile mythologies also advocate for client involvement and frequent feedback, another aspect where agile and software design come together naturally).

Let’s take for example a simple domain, that of a restaurant’s shifts management – the manager plans the following month’s shifts and publishes them as drafts to his employees which fill out their preferences and constraints. The manager then assigns employees to shifts according considering their input and republishes the final schedule. Our mission – take that process online and automate whatever is possible.

While the team speaks in terms of classes, database and builds, the manager speaks in terms of waiters, bartenders and schedules. The first step then is to create a common domain language between the domain expert and the team, a language that will be used throughout the development process.

To start modeling your domain, ask the expert some guiding questions. Identify your entities with verbs being their behaviors (/ methods) and nouns being their attributes (/ properties). For example, we’ll ask the manager of the restaurant to describe his process from end to end, which may be something like:

“A manager publishes an empty schedule with shifts in it so that employees can fill our their constraints and preferences until a given deadline. After the deadline, the manager assigns employees to shifts with respect to those preferences, and publishes the following weeks’ schedule.”

From that sentence alone we can probably understand that we have an entity called manager and a process that includes that manager assigning employees to shifts according to their constraints and preferences. We’ll name that process “Planning”. We also have an entity called schedule, with a one-to-many relation to an entity called shift, which itself has a many-to-many relation with an entity called employee. The employee has a one-to-many relation to constraint and preference. The employee also fills out his constraints and preferences in a process we can name “Submitting”.  We can also infer that a schedule is attributed with a start date, an end date and a deadline. All that from a single sentence – its objects, nouns and verbs.

Manager, Employee, Planning, Submitting and the rest of the underlined words are now added to our domain language. By keeping the conversation active, we can find out more and refine our model and our language - maybe constraints and preferences are the same entity with a different attribute? Maybe the schedule’s start and end date shouldn’t exist and are only defined by the first and last shift in that schedule? and so on…

In these sessions with the domain expert, be as creative as you’d like and use whatever makes you communicate the best – diagrams, white boards and drawings. Make sure to sum it all up and keep an updated domain language reference.

Since I’d like to keep this post at a “readable” size, I’ll divide it into a series of posts (soon to be actual links):

• Entities vs. Value Objects
• Architecture – Separation and Interaction
• Services, Aggregates, Factories and Repositories
• Refactoring - Constraints, Processes and Specifications
• Distillation and Generic Subdomains

Summary

When implementing DDD, make sure to:

1. Identify your domain expert, involve him in the process and create a common domain language (The “Ubiquitous Language”).
2. Model you domain into Entities and Value Objects according to the target domain, using:
   1. Aggregates to concentrate groups of entities and value objects under a single root entity.
   2. Services to implement stateless operations on multiple entities.
      1. Not to be confused with Web \ Wcf Services, we’re talking about Domain Services.
   3. Factories to separate creation of complex entities and their dependencies.
   4. Repositories to abstract the access to the data layer and stay loosely coupled from your implementation.
      1. Personally, I’m not sure that abstracting your data access framework is always a right decision, for example I do think that Service classes should include a property of ISession when using NHibernate, since the abstraction hides important features and it’s a price to pay, while OR/M isn’t something that you replace that quickly and may not need an abstraction.
3. Separate a big project into smaller modules, each with it’s own domain model, and try not to overlap. Where you can’t avoid overlapping, communicating between teams is the key, along with automatic integration tests and a CI server.
   1. Define the relationship between you different models (Shared Kernel \ Customer-Supplier \ Anticorruption Layer \ Open Host Service) and make sure your teams act accordingly.
   2. An updated and publicly displayed context map helps to see the big picture and keep in mind the connections between the different modules’ contexts.
4. Try to extract your core domain out of the entire domain and put you best people on it, that is what separates your application from the rest and that’s where your specialty should shine. for the other generic subdomains use one of the following:
   1. Off the shelf solution
   2. Existing model with an appropriate wrapping
   3. Outsourcing
   4. An in house implementation with lesser focus
5. Avoid common pitfalls:
   1. Modelers should also code – keeping your hands dirty keeps you in tune.
   2. Don’t over-abstract, talk in real life scenarios – implement the next step ONLY while keeping in mind the following ten steps.
   3. Apply DDD only when it fits – it’s perfectly Ok to use DDD on one module and not on another, all in the same global domain, as long as the communication between you domains

 

Few technical tips

1. Use an IoC framework, such as Castle WIndsor, Autofac or Spring.Net, after a small learning curve it’ll enhance your code’s maintenance.
2. Inject dependencies as high as you can in the application, to make you code suitable for as many contexts as possible (NH Session management is a good example for why dependencies should be injected and not created).
3. Use an OR/M framework and make sure that only the required project reference it and only the required classes use it.
4. Separate your code into projects, make sure to stay on “need to reference” bases only, to make sure you’re classes aren’t being abused.
5. Refactor, and then refactor again – if you’re afraid to refactor legacy code, write tests to cover it’s specs and then try again – it’ll even help you to better understand the requirements you’re implementing.
6. Use TDD to think before you code, starting is hard but it’s addicting.
7. Prototype anything you’re not sure of – performances, solution structure, etc..
8. Define a set of contracts and DTO’s as a single point of interface between two modules, don’t reference the other module’s core – it’s not yours!
9. COMUUNICATE – talk to you team, talk to you client, talk to your mother, just talk.

Want to know more?

Read this or this, or visit the DDD group at: http://groups.yahoo.com/group/domaindrivendesign

Phshewwww, that was long, but now that we’ve armed ourselves and laid down our design principles let’s get practical – in the next couple of posts we’ll be applying those tools and principles on our own application, using frameworks and tools like WCF, FubuMVC, NHibernate, Automapper and more.

For now, happy modeling.

Makes you wan't to open a session, doesn't it?

P.S

I have my hands full with exams this time of year, I'll post my pending drafts later this months - don't give up on me yet :)

Getting started – ARM YOURSELF!!!

Now that we’ve decided we’re going to build ourselves an application, it’s time to get the right tools for the job.

If you’ve never used ReSharper (R#) before (SAY WHAT?!?), make sure you download it and try it out. I can go on and on about how good it is, but I’m sure the screencasts will do a much better job. There’s a 30 day free trial after which you’re gonna have to pay to keep using it (or are you? ~_^ ), but once you get used to it you know it’s worth every penny.

My next must-have tool has to be TestDriven.Net, which is also FREE! (for personal use) and lets you run and debug unit tests (I find it faster than R#’s runner), display code coverage reports and, well, execute just about any basic piece of code when you need to run something quick and dirty.

After you install it you can use it by any of the following ways:

1. Right click a file, project or the entire solution in the solution explorer and choose you’re wanted action from the context menu (Run Test(s) \ Debug \ etc.).

Choosing “Run Test(s)” on the entire solution for example will execute every UnitTest in the solution (you can run more than one framework, let’s say NUnit and MSTest in the same solution, but each project will only run one framework)

The results show up in the output window, with failed tests also showing in the Error List.

2. Right click anywhere in the scope of a test method or fixture and choose your wanted action from the context menu. The test run include whatever was in the scope of your mouse pointer (method, fixture or even project).

The best part about it (wait for it…) is that it works on any method, even one without a Test\TestMethod attribute! A very useful feature in my view.

3. If you’re a keyboard freak like me, you’ll probably like this option best –> Right click on the toolbar –> customize –> Keyboard. Find the command “TestDriven.Net.Client” and assign an open shortcut for it, let’s say Ctrl+Alt+/ (don’t forget to click Assign).

Now while writing your test, you can just run it without leaving the keyboard!

Last but certainly not least, the latest addition to my arsenal is NuGet, the first widely used package management system for the .Net platform. For me at least it’s a very long anticipated tool that’s long overdue (very long, if we consider the fact the maven repository has been around since 2005 in the Java world), but better late than never!

It basically allows you to add a library package reference to your project directly from the official online repository (or your own) which hosts many OSS projects (or your own), doing that will download the package with it’s dependencies to a local cache, reference it and change\add .config and code as needed if the package had configured those actions. You can start using it by right clicking the solution explorer or manually using the new Package Manager Console.

Gone are the days of finding the right binaries, diving into an OSS project (Let’s say, NHibernate?) is as easy as adding a reference from the local GAC (minus the nausea)!

You can install it using the extension galley, but I recommend downloading the msi and running it, since I run into some voodoo the other day installing it via the gallery.

Oh, don’t forget installing the Productivity Power Tools via the extension gallery.

Well, now that we’re armed for the job, let’s get started with NHibernate.