Building distributed, scalable, systems is complex – and, even more common thanks to the growing number of IoT and mobile devices. A problem I routinely see is developers attempting to treat distributed systems like monolithic systems. Specifically, developers who hold on to patterns such as ACID.
Category: Software Design
Software Design Tip of the Fortnight: Tip #2
For this second installment of Software Design Tip of the Fortnight I want to talk a little about exceptions. Exceptions in .NET provide an excellent means of handling errors. We all know not to use exceptions for flow control, but there are many other ways to abuse exceptions.
Abusing exceptions can be anything from throwing the base Exception class, to throwing more than just exceptions. But the most common abuse of exception handling is to simply suppress them. We have all seen applications that do something similar to:
SomeBusinessObject bo = SomeBusinessObject.LoadWithId(4); try{ bo.SomeIntValue = int.Parse(txtSomeTextField.Text); }catch{ //the value wasn't int... so ignore it. } bo.Save();
The problem with suppressing exceptions is that most components don’t just throw them for the fun of it, there is some underlying reason why the exception was thrown in the first place.
The above example appears innocent enough. Int32’s Parse method throws an exception if it cannot parse the input string. But what if in the future another developer decides that the business object’s SomeIntValue needs a certain business rules that limits the acceptable values.
public class SomeBusinessObject{ //other class code public int SomeIntValue{ get{ return _someIntValue; } set{ if(value < 0) throw new BusinessRuleException("Invalid value for SomeIntValue."); _someIntValue = value; } } }
Software Design Tip of the Fortnight: Tip #1
Database identifiers are not important… to your users. Sure database identifiers are important to the database, and they are important to your data access layer, but they are meaningless to the users of your application.
Software Design Tip of the Fortnight: Prelude
To design software is to attempt to understand the very logic that composes its parts. At best as software developers we make crude approximations as to the intentions of our applications. Even the most thorough requirements gathering cannot account for every last permutation, in much the same way that unit tests don’t guarantee that your system works.
Source Control Is For Toddlers
You read that correct, source control is for toddlers. Not for toddlers to use, but rather to protect us from them. Surely the sole purpose of products such as Subversion, TFS, et. al. was to protect society from these pint sized keyboard loving terrors.
A Generic Error Occurred in GDI+
You know you’re doing good when your application crashes with an exception as detailed as “a generic error occurred in gdi+”. That is about as, well generic, as it gets :- )
In my particular case I was constructing an Image down in my DAO using the FromStream method, like so:
Image result; using (FileStream file = File.OpenRead(filename)) { result = Image.FromStream(file); file.Close(); } return result;
I was doing this so that I could know for a fact that the file was being disposed of properly. I didn’t want to have any orphaned file references locking up the file in case I later needed to delete it.
The problem was that up in my UI I was attempting to call the Save method on Image to dump its contents out to the ASP.NET response stream, like so:
img.Save(HttpContext.Response.OutputStream, ImageFormat.Jpeg);
aspNETserve Without GAC Install
The topic has come up many times, and that is “Why do I have to register aspNETserve.Core.dll in the GAC to run aspNETserve?”. The answer to this question has to do with how aspNETserve uses the ASP.NET hosting facilities, so first some background information.
ASP.NET MVC – Decoupling RedirectToAction
The RedirectToAction allows a controller to do an HTTP redirection to an alternative action. This is essentially the MVC equivalent of just doing a Response.Redirect in ASP.NET.
Testing Software Contracts Using ContractTest
Contracts, both explicit and implied, are key in designing a working software system. An example of an explicit contract in C# would be the implementation of an interface, while an implied contract would be something along the lines of all business objects have default constructors. Contracts of both types are critical to the success of a software system, but how do you test for and enforce these contracts?
Explicit contracts are often enforced by the compiler and are not nearly as fragile as implied contracts. Using the ContractTest testing framework you can write test cases for many common implied contracts. You can incorporate ContractTest assertions directly into your existing unit tests. For the following examples I will be using NUnit syntax, but you could use most any other unit test framework.
For example, assume you want to test for the presence of a publicly accessible default constructor on one of your business objects. Such a test using ContractTest would look like.
using ContractTest.Assertions; using NUnit.Framework; using MyNamespace.BusinessObjects; [TestFixture] public class SampleTests{ [Test] public void Test1(){ ContractAssert.Type.HasPublicDefaultConstructor<BizObjectA>(); } }
The Design Of Code
Jonathan Starr in a recent post, asked his readers:
“As we software engineers refactor someone else’s code […] at what point is the new application essentially not the same as the legacy application that you improved?”