Posts tagged with 'patterns'
Jeremy Miller has created an open-source IoC tool called Lamar. This episode is sponsored by Smartsheet.
Show Notes:
-
Instead, consider Lamar for your IoC container needs.
-
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
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!
Eric Potter talks about the new pattern matching features in C# 7.
Note that this was recording at the Indy.Code() conference in a hallway, so the audio may be a bit noisier than usual. At one point a firetruck drove by.
Show Notes:
- Edsger Dijkstra lays out the three main control structures (I believe) in Structured Programming (with C.A.R. Hoare)
- Aptera blog
- Eric Potter's blog Humble Toolsmith
- What's New in C# 7 blog post by Mads Torgersen
Want to be on the next episode? You can! All you need is the willingness to talk about something technical.
Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTunes.
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.
- Here are 10 technology predictions that turned out to be false.
- What do you think about DRY parameter names?
- Remember "grammar" checkers in Word processors? Hemingway seems to be a more useful take on that.
- Generate Office Files (Excel, Word, etc) from C#
If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.
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.
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.
- 2013 Stack Overflow User Survey. 10% of users are working remotely full-time. I don't think they asked the question last year, but if they did, my bet is that percentage has gone up.
- Samuel L. Jackson does not like it, but Dennis Nedry loves Jurassic Systems.
- Add Undo/Redo to your application with PostSharp, using the Recordable Pattern.
- A way to deal with the Android slide-out menu and screen rotation.
If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.
