A fairly standard set up for me is to have a solution in which I have a Data project that contains an EF6 .edmx file, generated from an existing database. I then split the entities into a separate Entities project, and have a Repositories project that references them both.
The problem was, I wanted to write unit tests against the code, but couldn’t work out how to do it. This post shows what didn’t work, and then what did.
When refactoring, it’s often hard to see which methods can easily be moved to another class, and what depends on what. Visual Studio has a built-in tool that can make this pretty easy, and almost fun! For a quick video overview of the tool, see this Channel9 video. The current article covers a lot of what is in that video, but concentrates on how to use the tool for refactoring. It’s worth watching the video, as there is a lot more to this than will be shown here. Note: The dependency graph feature is only available in the Grown Up versions of Visual Studio, ie Enterprise, Ultimate or whatever-they-call-it-this-week versions Creating a dependency graph To get started, click the Architecture menu, choose Generate Dependency graph, and then For Solution… Sadly, you only seem to be able to do this for a whole solution (the For Include File option is for C++…
A few years ago, I blogged about how to implement an “Are you sure” pop-up in MVVM. Well, I’ve grown up (a bit) since then, and realised that the code there wasn’t testable. I therefore take great pleasure in presenting for your delight, a testable “Are you sure” pop-up in MVVM. Aren’t I kind 🙂
Being good boys and girls, we want to write testable code, so if by some miracle we ever get around to writing unit tests, we can run them safe in the knowledge that they stand a fetid dingo’s kidney’s chance of working! One of the main issue involved here is ensuring we keep all view-related code out of the view model.
This post explains how to do it (with some pointless pictures)
As my regular reader will doubtless remember, I recently blogged about the important lesson I learnt while solving problem 8. I prophetically commented there…
“So, am I going to contemplate my problem domain before diving in and coding next time? Probably not, but at least if I don’t, I might have some idea where to look when the bug reports come in!”
Hmm, I thought I was joking! Well, sadly I wasn’t.
As I briefly mentioned in my rant about the F# fanboy lies, I have been using Project Euler to help me learn F#. I have got as far as problem 8, which was to find the largest product in a series of digits.
Apart from the fact that this was an interesting problem, I learnt a very important lesson from this one, and thought it worth sharing.
As my regular reader will know, I love anything shiny and new, and so was intrigued when I came across F#. When I was an undergraduate (some 25 years ago, ulp!), I played around with Prolog, and enjoyed the different approach to programming it offered.
However, as my time in front of the computer is at a premium, my F# learning started off with reading books and blog posts late away from the computer, usually last thing at night, and not actually doing any coding. Like most C# developers who come across F#, my initial reaction (other than “Hey, that’s shiny and new, I want to learn it!â€) was “Why?†If you search around for terms like “why f#†and “c# vs f#†you’ll find that this is a very common question.
The problem is that the answers aren’t very good. Well, let’s be blunt, there are a lot of lies out there.
Whilst working a WPF window, I ended up dumping loads of small jobs onto another developer, as he was the main one working on the XAML file for the window, and if we both tried to edit the file, we ended up with conflicts. After dumping the umpteenth extra job on him, I was trying to work out if there is a way I could ease his burden a little. There had been quite a few new issues where the extent of my involvement had been to modify the database and update the model. After that, I had to pass it over to him, to avoid us stomping on each other when working on the same files. So, I got to wondering if there was any way we could split the new quote window up, so multiple people could work on it at the same time. I immediately rejected using…
What should have been a relatively easy job turned into a very complex one. How I did battle with SQL Server and (mostly) won. By the way, in case you’re wondering about the title (and the subheading below if you’ve looked further on), then you obviously haven’t read The Hunting Of The Snark by Lewis Carroll. If so, I strongly recommend you do, partly because it’s a wonderful piece of sophisticated nonsense, and mainly because it’s far more entertaining than this article! It was subtitled “An Agony In Eight Fits” with each section being described as a Fit. It seemed appropriate for what happened here… Fit The First – Background I had a request to allow the user to enter some keywords, and we would show all support tickets that used the keywords in any of a number of fields. As SQL Server provides a full-text search facility, this seemed ideal for…
I came across a situation recently in which we needed an object in the client. Due to the cost of creating this object, we didn’t want to create it when loading up the window as it might not be needed (if the user didn’t click the appropriate button), we didn’t want to store it on the window’s main object graph, but equally, we wanted to keep hold of it once it had been created. This situation is not uncommon, where you have to create a class that is expensive (in database or bandwidth terms) to create. The obvious solution to this was to have a private variable for the instance of Expensive, and a second private bool variable to indicate if the Expensive object had been created. We could check the bool before accessing the Expensive variable. Even better, we could create a property that wrapped this up. Imagine our class is wittily…
Every now and then, I have seen my CPU usage jump up to close to 100% on all cores, which can slow things down somewhat… This looks really impressive, like I’m working so hard that my machine can’t keep up with my frantic pace. Sadly, this isn’t always the truth! Looking at Task Manager, shows the culprit to be microsoft.alm.shared.remoting.remotecontainer.dll. If you are using VS2013 or later, and are not using the Community edition, you may notice some annotations above your methods and properties… This feature is known as Code Lens, and is one of those things that is really worth getting to know, as it’s a massive time-saver. Quick digression from the main theme of today’s symposium to tell you why it’s so good… By default, there are about five or six code lenses, but as I’ve changed my options to show only one, only that one is visible in the…
Leave a Comment