Skip to main content

Posts tagged with 'design'

Jeremy Miller has created an open-source IoC tool called Lamar. This episode is sponsored by Smartsheet.

Show Notes:

  • StructureMap has been sunsetted

  • Instead, consider Lamar for your IoC container needs.

  • Nested containers

  • At one point I was rambling about ASP.NET Core’s inability to use the service locator pattern. Some quick points:

    • Don’t use Service Locator, there are lots of other better patterns to use.

    • DO NOT DO IT.

    • If you absolutely need it: here’s a blog post about it.

    • I was incorrect in the podcast by making a sweeping statement about ASP.NET Core not having service locator. But for a very specific, narrow case where I wanted to use the service locator pattern recently, I was unable to do so. This might have been my own failing, or something that just isn’t possible with the built-in ASP.NET IoC. I have not tried this very specific, narrow use case with Lamar yet.

  • I plugged my book, AOP in .NET yet again.

  • Lamar is named after Mirabeau Lamar (a hero of the Texas revolution)

  • Paper: Inversion of Control Containers and the Dependency Injection pattern by Martin Fowler

  • Gitter room for Lamar

Want to be on the next episode? You can! All you need is the willingness to talk about something technical.

Music is by Joe Ferg, check out more music on JoeFerg.com!

Rachel Andrew is a member of the CSS Working Group and is working with CSS Grids.

Show Notes:

Rachel Andrew is on Twitter.

Want to be on the next episode? You can! All you need is the willingness to talk about something technical.

Music is by Joe Ferg, check out more music on JoeFerg.com!

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

Welcome! This is one of the most popular posts on my blog. Thanks for reading! If you're into podcasts, check out The Cross Cutting Concerns Podcast, with interviews about interesting and fun technology.

I've heard some talk on twitter, blogs, and at various user groups and conferences for a while now about using the command/query object pattern instead of the repository pattern for a data access layer, and all the benefits of doing so.

So, I decided to explore it for myself. I converted over my Ledger project, since it used repositories, has some complexity, but is not particularly large.

Ledger already uses Dapper, so I started with Dustin Brown's post on using command/query with Dapper. For the most part, I followed what he did exactly (I also had to finally get Ledger using an IoC container, which I had been putting off for a while). These are the four files I used to get started with the pattern:

Note that mine differs from Dustin's only in that his IDatabase contains two methods named Execute, whereas mine contains one named Query and one named Execute. Note that except for IDatabase, these all depend on System.Data.IDbConnection (which is what Dapper uses). So, if you want to use a different DB access library, you'll have to change these.

Now, you need to create queries and/or commands. A query returns data, a command manipulates data. Here's a command that uses Dapper to create a new ledger:

Note that the information for the new ledger is passed via a constructor. And here's an example of a query that returns a single ledger, given an ID number (note that the ID is a constructor parameter).

Here's an example of both of those command/query objects in action inside of a controller.

That's the mechanics of it. It was much simpler to code than it might sound.

I don't know if I'm ready to draw any definitive conclusions about this pattern yet, but here are my thoughts:

  • I'm not particulary happy with the ceremony involved when doing this in C#. Compared to repository, it's a bit of extra noise and typing to use Execute + new keyword + constructor parameters + private fields to hold arguments.
  • Organizationally, I don't have to think about which method goes to which repository anymore. Organization, then, is strictly a matter of folders and/or namespace, and changing those is not as costly. I like that.
  • I also like that instead of 2, 3, or even more repositories, I only need one IDatabase member in my controller.
  • I haven't gone hands-on with unit testing, but I don't anticipate it being much harder. I could also forsee that this pattern is less likely to result in broken tests when making changes to a repository's interface.

I am impressed, but I am not entirely convinced yet. I think this may need further research, especially when it comes to unit tests.

Matthew D. Groves

About the Author

Matthew D. Groves lives in Central Ohio. He works remotely, loves to code, and is a Microsoft MVP.

Latest Comments

Twitter