LIMO - LeastInMostOut methods

I've been experimenting with different guidelines to help me construct better code. In particular I've been pondering 'how to decide the best arguments for a method'. I started to consider this question a little more, while reviewing another colleagues code. I was struggling to understand what I didn't like about their code, and why. Finally I think I have a 'reason' why their code has a bad flavor to me.

The code was simple enough, but it took large, full agg-roots as parameters. What smelt funny was, only one little VO was needed, yet the class was now coupled to the full AR, without much reason.

As a result the class method was now coupled to the full AR, though it could have been much more reusable, simply by taking just the bit(s) needed. After some googling, and asking other seniors, I couldn't find anything to 'point at' and say, see this guy recons it's better not to couple the classes like that.

So now, here a post to 'point at'.

Guideline:

Methods should take least in arguments to do their job. They should return most out to callers (LIMO).

Why?

Taking the Least-in reduces coupling by only requiring the information needed by the method. It also improves readability by making it clear what the method needs. 

Return the Most-out data you can, this improves re-use of the method while reducing the need for change in the future (Open-closed principal).

Notes:

This does not mean every argument should be a string or some other native type. An arguments type help describes the constraints. For example a method "GetDataFromAServer()" should take a URI rather than just a String.

Another Trick I find useful is to look at how a method argument is used directly inside the method. If the argument is immediately converted to something else, then sometimes this is a clue that some refactoring may be needed.

I tend to return the 'most-data' so the caller can decided what is relevant to them. Some might think this leads to exposing internal class-structure, and I would agree. In my code 'returning the most' helps with unit tests, it also reduces re-coding. If / when I want to return less information, I generally have an interface to express this.

One last trick; at the moment I'm returning this on methods which would normally be void-return. The idea is that by returning this, I'm providing some info to the caller and making caller code flow more. I'm not wed to the idea, this does have a down-side. I now have some difficulty knowing if a method returns a new instance, or the same instance.

Lifetime trick when migrating to mvc.net core 1

Recently while migrating projects from MVC.Net 5 to core 1 rc1 (mvc6 / vNext) I ran into an IoC problem. I was using Autofac as my container, and had just migrated some MVC filters. The filters were registered in the container using Autofac, and bound to MVC as global filters using ServiceFilterAttribute; following the post http://www.strathweb.com/2015/06/action-filters-service-filters-type-filters-asp-net-5-mvc-6/>here
Unfortunately at run time Autofac threw an error “No Scope with a Tag Matching ‘AutofacWebRequest’ “ . There is a reference to the problem on the Autofac site here
The error indicates either

1. Trying to bind a long-life (singleton) object with a short-life (per request) object.
2. Trying to resolve a per-request object before there is a request scope.

With these clues I finally worked out the problem, I have a combination of ‘binding’ approaches in my project.
Some services are bound using Autofac modules, here I was using InstancePerRequest() lifetimes. Other services were bound using the MVC container interface, in particular using IServiceCollection.AddScoped().
Using the Autofac MVC extensions, I add the MVC container bindings to the Autofac continer via ContainerBuilder.Populate(). This method maps the service registrations into Autofac. The mapping converts IServiceCollection Scoped bindings to InstancePerLifetimeScope().
Bingo
So some services were bound with InstancePerReqest(), while others with InstancePerLifetimeScope(). After consolidating my bindings to all use InstancePerLifetimeScope(), problem solved.

A stupid Team City build error

I've finally got Team City to run on Azure with the built-in database. But I was having terrible trouble getting my unit tests (MSTest) to run.

The error: 'Could not load file or assembly Autofac ...'

Every thing looked fine. Local build / test worked like a dream. NuGet packages loaded. CI build log showed Autofac was nu-get downloaded, and build success... I even fell back to RDP to build-box and run tests; again, success.

So what was the problem?

I used a simple short-hand to tell team city where the test assembly was: src/core.tests/**/*.tests.dll. This was (unexpected, by me at least) picking up both

1. src/core.tests/bin/debug/core.tests.dll AND
2. src/core.tests/obj/Debug/core.tests.dll

Fixing it

The fix is simple, just use a more exact setting in Team City src/core.tests/bin/Debug/*.tests.dll

Resolving a content item url in Orchard

Recently I needed to create a link to edit a content item in Orchard. Orchard uses a url like http://mysite/Home/Admin/Contents/Edit/123, where the id corresponds to the content item id.

My first thought was to hand-craft the url, replacing the content id as needed. But I found a better way: use the item's meta-data. Firstly inject the orchard IContentManager as usual, then call IContentManager.GetItemMetadata() The returned ContentItemMetadata contains MVC route's, for my particular case, EditorRouteValues had all the data I needed.

In my exploration of Orchard, I am continually finding myself having to dive into the code to work out how to do things. So here is 'how' I finally stumbled on the meta data solution.

Firstly I knew the Content Control Wrapper performed some 'magic' which added a link to a content item's edit.
Alas so-far I have no special trick for getting from a feature to the code that implements it. But eventually I found Orchard.Core/Contents/ControlWrapper.cs which implements the feature as a IShapeTableProvider. In here we see Content is wrapped with a Content_ControlWrapper shape.

Since nothing particularly enlightening is happening, I went to the view for the shape: Orchard.Core/Views/Content.ControlWrapper.cshtml. In the view the Html.ItemEditLinkWithReturnUrl() caught my eye.

This ItemEditLinkWithReturnUrl() is an extension, tracked down to Orchard.Framework/Mvc/Html/ContentItemExtensions.cs

Navigating to find the core ItemEditLink helper, bingo, I found how the content item meta-data is used for route values.

Using async/await (TPL) with Orchard

While working on a module for Orchard CMS I ran into some problems trying to glue async (Task) based code with (classic) synchronous code.

Here's the set-up:

• Service TheMovieDb to call themovedb.org api.
• Service MovieInfo service to integrate TheMovieDb with Orchard.
• AdminController for front-end to call MovieInfo and coordinate views.

TheMoveDb uses Tasks, so I don't have to wait around for across-the-wire calls. MovieInfo uses Tasks, and integrates with orchard services. AdminController uses normal Action methods.

Being a TDD developer, all the pieces looked fine. But as soon as I put it together... splat.

It all starts with a deadlock (doesn't it always!). A quick google gets to Stephen Cleary (via SO) Don't Block on Async Code and Async and Await Armed with this I now at-least understand the problem.

Alas, at least in Orchard 1.6, async controllers are a no-go. It took a fair bit of searching, I finally found an SO article describing the problem. So (for now) I've settled on a sync / async solution.

Putting it all together:

• TheMoveDb service stays as a normal async service.
• MovieInfo service calls TheMoveDb with ConfigureAwait(false).
• AdminController stay synchronous; blocks on calls to MovieInfo, waiting for Result.

There was one last gotcha; anything after the await in MovieInfo service executes on its own thread. So no access to orchard services (such as WorkContext etc). To get around this I just had to take care to no need the 'orchard friendly' thread context after the await.

Azure web-role with warmup

To avoid the spin-up time on an Azure role, I use the IIS Application Initialization (formally warm-up) module. The module is available by default for IIS8, so it's easier if you can run your azure role on Server 2012 (osFamily=3).

The step-by-step instructions describe how to configure the module for use. Using this along side an article on programmatic configuring azure app pool settings, I've got enough pieces to create a RoleEntryPoint for the task.

You will also need to (find) and include a reference to the Microsoft.Web.Administration assembly. Oh, and in addition to configuring the module, be sure to set the IIS IdleTimeout to 0 (zero).

Putting it all together:

Loading ....

Display summary for content item in Orchard.

Lately I've been building skills using Orchard CMS.

I ran into a problem trying to display a list of content items; in particular the in-built summary approach for Orchard didn't suite. The in-built approach takes the first 200 characters and displays them via the shape: Parts_Common_Body_Summary. This shape is created down inside the ~/Core/Common/Drivers/BodyPartDriver.cs, to be served up via the Parts.Common.Body.Summary.cshtml view template. Then; within the template; the body's html is used to create a excerpt of the first 200 chars, displayed as a p.

For me, I wanted to be able to specify the summary shape using html described in the content item itself. Initially I looked at just customizing the template view, I think this approach may have solved my immediate problem, but I would have had (yucky) logic inside my view template. Sounds like a great excuse for creating a Module :D

Since this was my first Orchard module, there was quite a learning curve to piece together how-to go about this problem. I can recommend the Pluralsight training video's to help you get started. Otherwise the Orchard Doco can help. Of course, nothing beats learning by tracing code and figuring it out yourself :D.

Normal content part driver's in Orchard create a shape, which is then served up via Orchard (don't forget placement) and displayed using a view template. Initially I was inclined to follow this pattern, and create my own "Parts_MySummary" shape for use. For better-or-worse, I opted to alter the existing Summary shape, I'm not 100% this is a good idea, but hey, if the fine folk over on the Orchard Project are going to make such a highly flexible and extensible CMS, then this is the kind of thing that'll happen :O.

To over-ride the in-built shape, I use my own IShapeTableProvider to hook into the display of the Parts_Common_Body_Summary, and with the magic that is IoC tada!

Since I was there, the module is built using 3 strategies for the summary:

1. Default (fallback) to in-built
2. First paragraph - extract the first p element from the body
3. Explicit text - editor defines the summary text to use.

Ideally I would have made this more extensible; allowing for other strategies to also be used. But I couldn't work-out how to add shapes at run-time to represent different strategies. For now, if you want a different strategy: Add an ISummaryStrategy service and provide a better Part editor. I will have to re-visit when I learn more.

The final module is hosted on codeplex: http://kwdsummary.codeplex.com/

And published on Orchard Gallery: http://gallery.orchardproject.net/List/Modules/Orchard.Module.Kwd.Summary