Should you use Third Party Software Components?

Home » Advice for New Developers » Software Architecture and Design » Should you use Third Party Software Components?
Photograph of two people having an argument / strong debate

There are some good third party software components out there, that have been developed over many years.

Over the years, I personally have used www.devexpress.com with both Winforms and ASP.NET Webforms, www.telerik.com on ASP.NET Webforms and www.obout.com on ASP.NET Webforms.

Let me make the distinction between components and tools. This post is about components that you include in your software. Tools such as Resharper from JetBrains, JustDecompile, Fiddler and JustTrace from Telerik are excellent and highly recommended. In fact I don’t know what I would do without them.

Should you use third party software components? Well it depends.

If you are using Winforms and to some extent WPF, then considering third party tools to help with the UI layer is a good thing, because you will massively improve your Winforms user interface. DevExpress in particular has a very rich set of components for the UI, although there is no reason why you can’t mix and match and use components from a number of suppliers if your budget allows.

If you are using ASP.NET, then the picture is less clear. My personal preference are client side UI components such as jQuery UI and Kendo UI used with ASP.NET MVC. If you are using ASP.NET MVC it is very easy to create a good usable layered architecture using conventions from MVC, and your own design in other layers, perhaps with the help of Microsoft Entity Framework or Telerik DataAccess to do your object relational mapping.

For ASP.NET web development, I would highly recommend that you learn how to create code WITHOUT using the server side third party components first of all, so that you understand fully the problem you are solving and can work out what the benefits are in detail and if they outweigh the investment in money and time learning these tools.

Also, you should not let these tools into layers other than the UI layer without very careful consideration, especially if you don’t fully understand what they are doing. Assuming your application is more than just a small app with a couple of pages in it, its important that you get your architecture right and keep to its design principles without having third party tools muddy your waters.

Finally, some of these tool manufacturers DON’T WRITE REAL APPS. They employ bright young people straight from university who have no idea how to write anything more than a whizz bang very flash example that might be impossible to include in your app without destroying your own elegant, readable design and the principles of your own architecture. Not only that, they are closed companies in that they don’t want you to know how to write apps without them because I’m sure they fear that you might not use their services if you knew how to do it without them (nothing could be further from reality in my view).

These are the things you should really be thinking about, not just the time you think you might save by using third party components.

I hope to cover this subject more in future posts on software architecture and design.

About Phil

I have been working as a software developer since 1983. This blog could have been called "From Fortran 77, C and Cobol to C# in 20 (not so) easy years", but it doesn't sound quite right somehow. Besides I'm talking about what's happened since 2003, not before!

Leave a Reply

Your email address will not be published.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">




Top Posts & Pages

Categories

Recent Posts

Recent Comments

Archives

Blogroll

  • Mike Cohn's Blog
  • Scott Hanselman's Blog
- mike@mountaingoatsoftware.com

Pervasive myths about agile get in the way of success. It’s time to bust six of those myths. [...]

- mike@mountaingoatsoftware.com

Agile teams strive to finish work in the same iteration in which its begun. Here’s why that is so im [...]

- mike@mountaingoatsoftware.com

I wrote 25 blog posts during 2018. In case you missed some of them, here are the most popular. [...]

- mike@mountaingoatsoftware.com

The iterative and incremental nature of agile makes an agile approach seemingly less compatible with [...]

- mike@mountaingoatsoftware.com

Velocity can be great for predicting how much a team can deliver in a given period. But it needs to [...]

- Scott Hanselman

I've been exploring nopCommerce. It's an open source e-commerce shopping cart. I spoke at [...]

- Scott Hanselman

The optical disc drive is giving out on my GoldStar 3DO machine. It's nearly 30 years old. I wa [...]

- Scott Hanselman

I've long blogged about the intersection of diabetes and technology. From the sad state of diab [...]

- Scott Hanselman

Back in the day, making a Minecraft mod was...challenging. It was a series of JAR files and Java hac [...]

- Scott Hanselman

I've been using ILMerge and various hacks to merge/squish executables together for well over 12 [...]

Meta