IExtendable while (this.IsAlive) self => self.UpdateAll()

25Jan/130

Recursive Mocks with Rhino Mocks and NSubstitute

I just learned that you could do this:

Update: 2013-01-25
Note that successive chained mocking calls to RhinoMocks fail. I now have a reason to prefer NSubstitute other than it's beautifully simple API.

Tagged as: No Comments
6Dec/121

The Value of Features of ORM’s

At Redacted Associates, we’ve been having a discussion about whether we should use the Generic Repository pattern on top of NHibernate. We have a simple IRepository interface as follows:

For my part, I like don’t like to spend a lot of time worrying about the way my ORM interacts with the database. I prefer to spend my design-energy around how to architect the application such that interacting with the database is a minor implementation detail, almost an afterthought even.

At least one of my co-workers disagrees, and has given a really good argument for a specific case when using direct features in NHibernate saved some work. This discussion has spurred me to ask myself “what are the most important features of an ORM?” and “at what level of abstraction should we work with an ORM?” There’s no way to answer these questions without identifying your purpose in using the ORM to begin with. With that in mind, I decided to categorize the features we all look for in an ORM and compare them to our Generic Repository implementation.

ORM features basically fall into one of 3 categories:

  1. Queryability

    • Linq Provider

      In .NET, Linq remains the most discoverable way to query an ORM. NHibernate has the QueryOver api, but I find it to be hopelessly unreadable anything but the simplest query.

    • Specification pattern

      The easiest specification pattern in .NET relies on Linq. It’s a very nice way to allow api clients to construct their own queries without concerning themselves with database schema details. In an SOA architecture, it provides a flat contract to support complex query results. It minimizes the number of service methods because you don’t have to write GetCustomersByNameAndCityAndProduct.

    • Fully mapped relationships between objects.

      I depend on having a fully expressed query model to use for linq queries. Getting the right data to work with often involves a number of database relationships and it’s impossible to predict when some new object or property will be needed to satisfy a query. It’s easiest to ensure that the model fully expresses the database and that all fields and relationships are present in the model. The model should fully and accurately express the database schema.

    • Id navigation properties.

      Id navigation properties as a companion to the object relationship properties are really handy. They can reduce query-syntax clutter quite a bit. Employee.ManagerId is cleaner than Employee.Manager.Id. Some ORM’s will pull back the whole Manager to get the Id. I hate that.

    • Full support for all relationship types (one-to-one, one-to-many, many-to-many).

      These relationships are standard in relational db’s. Any Object-Relational Mapper should support them.

    • Lazy Loading
  2. Behavior

    • Cascade mappings.

      This is not personally a value to me, but I recognize that in some cases it’s useful.

    • Trigger-behavior.

      This sort of behavior is useful when you want the ORM to handle things like audit fields, soft deletes, or log table entries.

    • Sql-Efficiencies.

      Sometimes pulling back large datasets and mapping them to in-memory objects can be very expensive. If performance is a concern, it’s nice to be able to have the ORM optimize the operation. NHibernate’s “Merge” operation is a good example of this.

  3. Testability

    • In-memory testability
    • Mockable/Stubbable

I composed the following table listing the features we are seeking from an ORM and how each tool fares against our needs.

NHibernate
Entity Framework
Generic Repository
Micro ORMs
Linq Provider
Not Fully Implemented Fully Implemented Depends on ORM No
Specification Pattern
Easy to implement against partially implemented Linq provider. Hard otherwise. Easy to implement. Depends on ORM No
Can Fully Map Relationships
Yes Yes Depends on ORM No
Id Navigation Properties
Not without extreme (and not very useful) hacks Yes Depends on ORM Yes
Full support for relationship types
One-to-one doesn’t work well. Results in N+1 queries on one side of the relationship * Haven’t tested this. Depends on ORM Sort of
Lazy Loading
Yes Yes Depends on ORM No
Cascade Mappings
Yes Yes Depends on ORM No
Trigger Behavior
Yes Yes Depends on ORM No
Sql Efficiences
Yes Yes Depends on ORM No
In-memory testability
Yes, provided you use SqlLite. Yes, provided you use SqlCompact edition—or you can interface your DbContext. Yes No
Mockable-Stubbable
Mostly. Some of the methods you use on ISession are in fact extension methods. .Query is an extension method which is problematic since that’s an obvious one I’d like to stub. Mostly. Methods such as .Include() are extension methods with no in-memory counterpart. If I really need to use .Include() I’ll write an integration test instead. Yes No
Notes
  • ISession.Query is an extension method. Not testable.
  • ISession.QueryOver is a difficult api for complex queries, especially those involving groups.
  • Automappings make map-by-configuration easier.
  • No (current) support for convention-based configuration.
  • No Merge operation.
  • Generic repository does not give you direct access to methods like ISession.Merge.
  • You have two ways of dealing with this:
    1. Use ISession (or DbContext) directly.
    2. You can inherit or adapt the IRepository interface to provide the other methods.
Fantastic for quick and dirty CRUD on single tables. Not so great otherwise.

 

Takeaways

My advice is to use Generic Repository except when you need to get close to the metal of your ORM for some fine-grained control over your data access.

2Nov/120

IlMerge in TeamCity

I wanted to IlMerge an assembly in a TeamCity project. TeamCity has a Powershell build step that you can use to run your own arbitrary scripts. Here’s how I did it

TeamCity Configuration

image

Powershell Script

31Oct/120

Isg.EntityFramework.ObservableProvider

The Problem

I’ve been struggling for awhile to figure out how to get Entity Framework to set and unset application roles in Sql Server when opening and before closing a connection. The problem is that ConnectionState does not provide a Closing state that fires before a connection is closed.

It was suggested to me to turn of connection pooling. Errrr, no. We want connection pooling for our applications. I also don’t want to have to manually open and close the connection every time I create a DbContext. That’s just messy and irritating.

The next obvious thing to do would be to create a DbConnectionDecorator to wrap the existing database connection and expose the Closing event. This proved to be very difficult because Entity Framework does not expose when and how it opens connections.

Grrrrrr.

The Solution

What’s that you say? I can implement my own EntityFramework Provider? There’s a provider wrapper toolkit I can plug into to do this? Awesome!

Oh wait—that looks really, really, REALLY complicated? You mean I can’t just decorate a single object? I have to decorate a whole family of objects?

Hmmmm.

Alright, tell you what I’ll do. I’ll implement the provider wrapper using the toolkit as best I can—but then I’m going to strip away everything I don’t actually need. Besides, if I just make the various data related events observable, it’s nothing to Trace the output. And Cacheing can easily be added as a IDbContext Decorator anyway. I don’t really get why that should be done at the Provider level.

Configuring Your Application to use the Provider

To use the new provider, first install the package. At application startup, you’ll need to register the provider and tell it which other provider you are wrapping. The registration process will set the ObservableConnectionFactory as the default connection factory used by EF unless you pass the optional setAsDefault:false.

Consuming the Provider Events

ObservableConnection exposes several new events, including Opening, Opened, Failed, Closing, and Closed. However, to subscribe to those events directly requires that you cast the DbConnection exposed by EF to ObservableDbConnection, which strikes me as a little cumbersome (not to mention a violation of the LSP). My first use case demands that I handle the Opening and Closing events the same way for every DbConnection application-wide. To that end, ObservableDbConnection (and ObservableDbCommand) pushes its event messages onto a static class called Hub.

Guarantees

This code is brand-spanking new and it hasn’t had time to bake yet. I’m using it, but it’s entirely possible that there are unforeseen problems. Feel free to report issues to and/or contribute to the open-source project on BitBucket. Until then, know that it has been rigorously test and that it works on my machine.

works on my machine, starburst

17Oct/120

Review: HTML5 Conference in Austin, TX

I didn’t realize this when I signed up, but the DevCon5 Html5 Summit was a conference within a conference. The larger conference was an ITEXPO. The ITEXPO conference was focused more on infrastructure than development—in fact as far as I could tell, HTML5 was the only developer-centric conference at the entire event. This did not turn out to be a good thing for me. I noticed maybe 20 or 25 developers for the HTMl5 portion of the event.

The Negative

The sessions themselves had a few problems. First, the focus was almost all on mobile and app development. I realize that the world is changing and that more and more people are developing for the mobile platforms, but there are an awful lot of us that are building applications for the business we are trying to support. It would be nice if someone would discuss benefits to the business of the new HTML5 goodies. There was a little of that in the sessions, but it wasn’t very meaty. Yes, it’s great that you can make images float across the page, but my business users don’t really care about that.

The second problem, which perhaps isn’t the speaker’s fault, is that no one was really super-excited about HTML5. Since the focus was on apps for the mobile platforms, most speakers spent time acknowledging that the write-one-run-anywhere promise of HTML5 isn’t a reality, and likely wont’ be for a long time (but it’s getting better!).

Another issue with some of the speakers is that they did not seem to know very much about HTML5. If I had to reverse-engineer their talk, I would say that there was something they wanted to learn about, they learned just enough about it to fill up an hour of speaking, and then stopped. They were unable to answer questions about possible uses for the bits they were covering beyond their demo. Several speakers also did not have working demos.

The Positive

The best part of the sessions is that I got a lot of tools and references to other sessions that might fill out some of what’s missing. Here are some of the things that were referenced:

There were a very few principles and practices discussed. They are:

  • Get familiar with messaging in javascript.
  • If you’re going to support mobile, develop for mobile first—then the desktop.
  • 1 class per js file.
    • I especially like this one because it implies that you should still be writing classes in javascript.

Presenters I’d Like to See Again

Instead of picking on the presenters I thought were less than spectacular, I thought it would be better to shout the names of those who were particularly good. These are people that I’d enjoy talking to about web development again.

  • Jonathon Morgan – His talk on HTML5 vs. Native apps was well-reasoned and balanced. His enthusiasm for development was refreshing.
  • Tom Shafron – He is the current CEO of Viewbiquity. His session was on machine-to-machine communication in javascript. It was in his talk that we got into javascript best practices and patterns.
  • Jesse Cravens – His session on node.js was substantive and interesting. Most of the libraries mentioned above came from his presentation.
Filed under: Conferences No Comments
28Aug/120

Simple.Validation 0.6.1 Released

What’s new?

Testability has been kind of an issue for us with code that relies on the static Validator class. To improve the situation, I added IValidationEngine as an alternative. Validator is still fully backwards compatible

  • Addition of the IValidationEngine interface
  • The DefaultValidationEngine requires an instance of IValidatorProvider for its constructor
  • Validator.SetValidatorProvider() has been marked obsolete. You can still use it, but it will have the side-effect of over-setting Validator.ValidationEngine to a new instance of DefaultValidationEngine.
  • Added a NinjectModule to Simple.Validation.Ninject that configures the DefaultValidationEngine and DefaultValidatorProvider automatically.
15Aug/120

Install-VSCommandPrompt Powershell Script updated

Tagged as: No Comments
15Aug/120

API Design: Batch Operations

When designing a batch API, it is important that the return results be relatable to the individual arguments that were asked to be processed.

Consider an API that takes a list of objects to perform an operation on. It might have a method signature that looks like this:

        Response Process(Record[] records);

 

What is a good design for the Response object? I recently encountered a situation in which I was given a response object like this:

    public class Response
    {
        public bool Success { get; set; }
    }

 

Okay, actually it was more like this:

        bool ProcessTheRecords(int[] ids);

 

The problem with this approach is that when the operation fails there is nothing on the Response to indicate the nature of the failure. A better Response object might look like this:

    public class Response
    {
        public bool Success { get; set; }

        public OperationResult[] ErrorsAndWarnings { get; set; }

        public ProcessRecordResult[] Results { get; set; }
    }

    public class ProcessRecordResult
    {
        public string RecordIdentifier { get; set; }

        public OperationResult[] ErrorsAndWarnings { get; set; }
    }

    public class OperationResult
    {
        public string Message { get; set; }
        public Severity Severity { get; set; }
    }

    public enum Severity
    {
        Error = 1,
        Warning =2,
    }

Why is this better? Response.ErrorsAndWarnings lets me see if anything went wrong with the operation outside of any particular record. There should be a ProcessRecordResult for each record passed into the method call. Each ProcessRecordResult has its own list of ErrorsAndWarnings that indicates what may or may not be wrong with a specific record.

The purpose of the response object is to give enough information to the caller so that they can adjust their failed request into a successful one. Minimize the size and shape of the data required to perform the operation. Maximize the size and shape of the data required to understand what went wrong during the operation. These principles apply to non-batch operations as well, but they are especially frustrating when there’s an error in one of hundreds of records.

Tagged as: , No Comments
18Jun/120

Simple.Validation 0.5.0 Released

New Feature

Message() method has been overloaded to accept a function to build the validation message while the object/property is being validated.

Example:

var validator = Properties<Employee>
    .For(e => e.FirstName)
    .Required()
    .Message((context, value) =>
        {
             customMessage = string.Format("Custom Message format '{0}'", value);
             return customMessage;
        });
30May/121

Origin Story: How I Became a Software Developer

Scott Hanselman recently posted his story about how he became a software developer. This is mine.

I was in debt. And I needed money.

When I was in my early 20’s I didn’t have much going for me. I had quit high school in the 10th grade and mainly worked in the fast food industry. I didn’t have much money, but I wanted stuff—so I use credit cards heavily. I got in over my head really fast.

I had been toying with school. I was half-assedly pursuing a philosophy degree, but I wasn’t really putting the effort into that that I should have been. I was unhappy, alone, and going nowhere fast.

At 25 I had a realization—if I met the kind of woman I wanted right then, she would want to have absolutely nothing to do with me. It was a slap in the face. I had this high standard that I expected my future romantic partner to live up to, but I had done nothing to merit her attention. I was a loser.This was my way of judging myself by my own standards. Something had to change.

I had recently seen an article in the newspaper about a high school kid making $50k/year building websites in his spare time. This amount of money seemed unfathomable to me. With that kind of money, I could pay my debts and be on my way. This encouraged me to take some programming classes at the local community college. I had to make some arrangements with my employer so that I could leave work in the middle of the day for classes. I would get to work at 8AM, leave for class around noon, and come back and work until midnight or so. It was hard.

I struggled with nested for-loops in the bubble sort algorithm, but I had a knack for organizing my code in a readable fashion. I managed to get through QBasic, C, and Visual Basic before I decided to submit my resume at the school’s job board.

I got lucky.

It happened that a local company was looking for someone that they wouldn’t have to pay very much and that they could train to work on their software. I had a message on my answering machine from Benny when I got home from school that day.

We scheduled the interview and I showed up with my code-sample—a windows form with a set of radio buttons that toggled an image of a flag for an associated country. I knew it wasn’t much, but I wanted to show that I could do something. I think Benny barely looked at it. The interview actually went well. Benny gave me an overview of the application we would be working on. Their customers were the fast-food industry so my experience there would help a little bit. At least I understood the business domain. After a little probing about my skills, we started talking about “South Park” for another 20 minutes or so. A friendship was born.

Apparently they were desperate. One of my competitors for the job had picked a fight with the secretary before the interview even started! Benny called me a couple of weeks later to tell me that I got the job. I was desperate too. The money wasn’t much—in fact it was a pay cut for me since I would be salaried without overtime compensation. I took the job.

Working with Benny was a revelation. He knew that I didn’t know much, but he also knew that I had a brain in my head and a willingness to learn. He was patient with me while I applied myself and learned to be an effective contributor to our application. My skills grew over time and inside a year I could add to the system almost as easily as he could.

It was 5 years before I managed to pay off my debt. In that time I had learned much about software algorithms, patterns, and practices. I had started my first steps down the road of agile software development practices. I was reading everything I could get my hands on about better ways of writing and managing software. I was evangelizing what I had learned to my co-workers. I started down this path to find a way to pay my bills without filing for bankruptcy. What I found was a passion for a profession that I’m actually pretty good at, and a great new friend.

Benny and I are still friends to this day. We’ve moved on to different jobs, and I moved 3000 miles away to Seattle (I’m hoping to convince him and his wife to move out here!) I shudder to think what might have happened to me had I not been lucky enough to get my start in this field. Getting my foot in the door with him is one of the greatest things that’s ever happened to me.

Thanks Benny.

Tagged as: 1 Comment