If you’re a .NET developer, then it’s overwhelmingly likely that you’re a Visual Studio user. There are alternatives to it, sure. But the product from the Redmond giant is the go-to when it comes to developing for the .NET framework.
For a newcomer, though, things can get confusing since Visual Studio isn’t a single thing.
Instead, it comes in several shapes and sizes.
Which one should you pick? What are the features that matter for your use case?
Since Visual Studio isn’t free—most editions aren’t, at least—you want to get the best bang for your buck.
That’s what this post is going to cover. As its title suggests, we’ll focus on the differences between the enterprise and professional editions of the integrated development environment (IDE).
By the end of the post, you’ll have learned enough to make an informed decision on which version of the IDE better suits your needs.
Wishing your edition of Visual Studio had full architecture tooling support?
Download a free trial of NDepend and check out all of the architecture visualization you can get without needing to upgrade your VS edition.
Let’s get started.
Continue reading Visual Studio Enterprise vs. Professional: Essential Differences
Domain-driven design, or DDD, is a software design methodology aimed at producing better software. Engineers achieve this by working closely with domain experts during the continuous design process.
Eric Evans created domain-driven design and wrote a book about the practice called Domain-Driven Design: Tackling Complexity in the Heart of Software. His main points are to use models, use the language of the business, and follow specific technical patterns during development. Together, these steps will help you deal with complex software without painting yourself into a corner.
In this post, I’ll go further into demystifying domain-driven design. First, I’ll share a story about how I came to know the practice myself. Then I’ll get into some details about the modeling part of the process. Finally, I’ll do an overview of the technical bits of the craft.
Continue reading Domain-Driven Design Demystified
There’s a common misconception that’s permeated our profession: Architects don’t need to write code to do their jobs.
Now, this may seem like a harmless approach. After all, writing code is what developers do. And architects should be busy with more important tasks.
However, keeping architects from writing code can limit the potential of your development teams. It can also result in an architectural mess when requirements and business needs change.
So today let’s look at why giving your software architect time to write code is a good thing. But first, we’ll start off by looking at what life is like as an architect.
Continue reading Should Architects Write Code? You Bet They Should!
Hexagonal architecture is a model or pattern for designing software applications.
The idea behind it is to put inputs and outputs at the edges of your design. In doing so, you isolate the central logic (the core) of your application from outside concerns. Having inputs and outputs at the edge means you can swap out their handlers without changing the core code.
In this post, we’re going to take a look, in detail, at just how hexagonal architecture works. But first, let’s talk about why this is desirable.
One major appeal of using hexagonal architecture is that it makes your code easier to test. You can swap in fakes for testing, which makes the tests more stable.
Hexagonal architecture was a departure from layered architecture. It’s possible to use dependency injection and other techniques in layered architecture to enable testing. But there’s a key difference in the hexagonal model: The UI can be swapped out, too.
Interested in seeing what your codebase’s architecture looks like and whether it exists in the Zone of Pain?
Download the NDepend trial for free and see if your actual architecture matches your design documents.
And this was the primary motivation for the creation of hexagonal architecture in the first place. There’s a bit of interesting trivia about its origins. The story goes a little like this….
Continue reading Hexagonal Architecture: What Is It and How Does It Work?
Today’s post attempts to answer a very simple and straightforward question: “When is it OK to use a C# partial class?” And the answer as straightforward as this: “When you need to allow the user to edit code that was automatically generated.”
Whoa, that was hands down the easiest post I’ve ever written. So, that’s it for today, folks. Thanks for reading and see you next time!
OK, I’m just kidding, of course. If you’ve found this page by googling around on “C# partial class,” chances are you have a number of questions regarding this topic. For starters, what is a partial class? How do you actually use it? Are there any restrictions regarding its use? And the list could go on.
That’s what today’s post is all about. We’ll start out by explaining what a partial class is and providing some examples. Then, we’ll go a little bit deeper, giving a more detailed view of the partial class, its inner workings, and the rules that must be followed when using it.
Finally, we’ll explain the main use case for the C# partial class, nicely tying the end of the post to its beginning.
Continue reading When Is It Okay to Use a C# Partial Class?
A bunch of years ago, I wrote a post on my own personal blog titled, “Why I Don’t Like C# Extension Methods.” Over the years, I’ve updated that post a bit, but mostly left it intact for posterity I guess. But if you ask me how that post has aged, I’d respond with “it’s complicated.”
I didn’t like extension methods back then. I do like them now, provided they aren’t abused.
So, what gives? Am I just a hypocrite? Or is it a matter of growth?
Well, none of the above, I’d argue. Instead, the programming landscape has changed and evolved. And I’d submit that extension methods were actually ahead of their time when the language authors came up with the concept. But now they’re hitting their stride.
Don’t take my word for it, though. This is another one of my research posts, whose previous ranks have included how functional approaches affect codebases, what unit tests do to code, and a look at singletons. Today, we’ll take a look at extension methods and what properties of codebases they correlate with.
Continue reading Extension Methods and the Decline of Traditional OOP
I really love the name “shotgun surgery” for describing a code smell. It’s sort of an interesting mix of aggressive and comical, and so it paints a memorable picture. I kind of picture Elmer Fudd blasting away at a codebase and then declaring “ship it” and doing some kind of one-click production push.
But misappropriating Looney Tunes aside, what actually is shotgun surgery?
Well, it’s a specific code smell in your codebase. Shotgun surgery happens when you have to make many changes in your codebase to achieve seemingly simple tasks. Often, you’ll find yourself making changes to code that seems pretty similar, either copy-pasted directly, or else of similar intent.
Continue reading Shotgun Surgery: What It Is and How to Stop It
So you’ve read about the Onion Architecture and think you get it. There are layers in this architecture. They’re onion-like. And they make your code better.
But how? And what do you put in each layer? And how the heck do you get your repository to be on the outermost layer of this onion?
Continue reading Onion Architecture: Going Beyond Layers
There was a time when Linq was a mystery to me. But, now that I’ve learned how to use it, I don’t know how I ever lived without it! You’ll learn Linq with this complete beginner’s gentle introduction. All you need to know before you start is how to code a loop. Heck, I’ll even show you that first. Ready? Let’s get started!
Continue reading Linq Tutorial: A Complete Beginner’s Gentle Introduction
Quite often we talk about architectural concerns on this blog, with topics like application layering or the merits of design patterns. But today I’m going to switch gears a little and talk about your wallet.
Oh, don’t worry. We’re not going too far afield. I’m going to talk about how your developer tools purchases affect your wallet.
When it comes to product support, you probably don’t give this a ton of thought. At least, you’re probably more focused on features, what problems the product solves for you, what the price is, and so on. The support arrangement probably matters somewhat to you, but doesn’t rise to top of mind.
But today, I’m going to ask you to think about it a little bit. And I’m going to suggest that you give a quick consideration during future purchases as to how support works. Simply ask yourself, “does this vendor ask you to pay extra for support?”
If the answer is yes, that’s a smell.
Continue reading You Should Favor Software Products That Include Support in the Price