What basic architecture can I use for a single layer Windows Forms app?

Question

I have an extremely basic Windows Forms app for data capture and reporting on microloans. I have done a pretty good entity model design using EF, but only some initial prototyping with data access via the EF as well as business logic inside Windows Forms methods. I want to now 'formalise' the app a bit, and concentrate on writing only UI logic in the forms themselves.

I'm wondering what structures and patterns I can use here? I am used to using a loose repository pattern and view model setup for my MVC3 projects, but haven't done much winforms work for a few years and am unsure. Some recent reading suggests a repository should purely do CRUD, which would make using one here superfluous and excessive. I don't want to go as far as a full-on MVVM or MVP design, but I'm stuck wondering where to put what.

The most apparent structure that emerges for me is to extend my entity model to include business logic and operations, e.g. add an AllocatePayment method to the Client class, to allocate a payment made by a client over outstanding loans for the client, and so forth, but this doesn't smell quite right. Even worse is the looming LoanManager type monolith class, with static methods for everything.

How can I nicely refactor this prototype into a presentably structure app design? I would like to incorporate a TDD approach now, before beginning the refactoring. It seems this will help inspire better low level design of whatever class structures I decide on.

score 1 · Answer 1 · answered Mar 12 '12 at 02:59

I don't know WinForms (Or EF or really .NET for all that matters), but I'll make a suggestion based on what I do know (or think I might remember).

Lets assume you have a simple form class that calculates risk based on 3 variables, Age, Amount, and Hair Color. When clicking the "Rate" button a label will be updated with the appropriate string: "High", "Medium", and "Low".

public void btnRate_click() {
  var RiskScore = 0;
  if(txtAge.Value < 25)
    RiskScore += 2;
  else if(txtAge.Value < 40)
    RiskScore += 1;

  if(txtAmount.Value < 2.00)
    RiskScore += 10;
  else if(txtAmount.Value < 10.00)
    RiskScore += 3;
  else if(txtAmount.Value < 50.00)
    RiskScore += 5;

  if(txtHairColor.Value == "Red")
    RiskScore += 75;

  if(RiskScore < 2)
    lblResult.Value = "Low";
  else if(RiskScore < 8)
    lblResult.Value = "Medium";
  else
    lblResult.Value = "High";
}

Given this code, I would start with some simple "Prefactoring" before laying down some tests. I tend to use standard refactorings that IDEs such as ReSharper can do automatically because they're really safe to do and rarely leave unwanted side effects.

The first thing we'll do is remove the duplication in the code. Specifically by extracting some local variables.

public void btnRate_click() {
  var RiskScore = 0;
  var Age = txtAge.Value;
  if(Age < 25)
    RiskScore += 2;
  else if(Age < 40)
    RiskScore += 1;

  var Amount = txtAmount.Value;
  if(Amount < 2.00)
    RiskScore += 10;
  else if(Amount < 10.00)
    RiskScore += 3;
  else if(Amount < 50.00)
    RiskScore += 5;

  var HairColor = txtHairColor.Value;
  if(HairColor == "Red")
    RiskScore += 75;

  var Result = ""
  if(RiskScore < 2)
    Result = "Low";
  else if(RiskScore < 8)
    Result = "Medium";
  else
    Result = "High";

  lblResult.Value = Result;
}

This refactoring was quick and can be accomplished automatically using Ctrl+Alt+V We'll now take a moment to organize the code slightly, moving the variable declarations around.

public void btnRate_click() {
  var Age = txtAge.Value;
  var Amount = txtAmount.Value;
  var HairColor = txtHairColor.Value;

  var RiskScore = 0;
  var Result = ""

  if(Age < 25)
    RiskScore += 2;
  else if(Age < 40)
    RiskScore += 1;

  if(Amount < 2.00)
    RiskScore += 10;
  else if(Amount < 10.00)
    RiskScore += 3;
  else if(Amount < 50.00)
    RiskScore += 5;

  if(HairColor == "Red")
    RiskScore += 75;

  if(RiskScore < 2)
    Result = "Low";
  else if(RiskScore < 8)
    Result = "Medium";
  else
    Result = "High";

  lblResult.Value = Result;
}

What we've now managed to accomplish is to isolate the business rules (the risk calculation) from the UI components (the form controls). The next step is to get those business rules out of the UI class and out into somewhere else. Another refactoring is in order now. In looking at this code, there are four variables being operated on in this method. When the code operates on the the same variables, it's often a sign that a class is lurking in there. Let's use the Extract Method Object refactoring here... (I don't remember this keystroke but I'm pretty sure it's in there)

Looking at what this block of code does, we'll call this new class the RiskCalculator. After the refactoring the code should look something like:

public void btnRate_click() {
  var Age = txtAge.Value;
  var Amount = txtAmount.Value;
  var HairColor = txtHairColor.Value;

  var Result = new RiskCalculator(Age, Amount, HairColor).Invoke();

  lblResult.Value = Result;
}

// In RiskCalculator.cs
public class RiskCalculator {
  private int Age;
  private double Amount;
  private string HairColor;

  public RiskCalculator(int Age, double Amount, string HairColor) {
    this.Age = Age;
    this.Amount = Amount;
    this.HairColor = HairColor;
  }

  public string Invoke() {
    var RiskScore = 0;
    var Result = ""

    if(Age < 25)
      RiskScore += 2;
    else if(Age < 40)
      RiskScore += 1;

    if(Amount < 2.00)
      RiskScore += 10;
    else if(Amount < 10.00)
      RiskScore += 3;
    else if(Amount < 50.00)
      RiskScore += 5;

    if(HairColor == "Red")
      RiskScore += 75;

    if(RiskScore < 2)
      Result = "Low";
    else if(RiskScore < 8)
      Result = "Medium";
    else
      Result = "High";
    return Result;
  }
}

Now we're getting somewhere. Your RiskCalculator contains only business logic and is now testable. The next step is to write some unit tests around the calculator, validating all of the business rules. This will give you the ability to refactor and clean up the actual calculation code.

Through the activity of writing the tests you may notice that RiskCalculator isn't really a good name for this class. I mean, if you think about it the data that's being passed into the constructor actually represents your loan! Given that you have a good base of tests for the current RiskCalculator you can perform a couple of Rename refactorings. We'll start with Rename Method.

The Invoke method is really uninformative as a name, so we'll rename it. What is it doing? I'd say it's actually performing the risk calculation, so let's call it calculateRisk. After that, we have to ask ourselves what it's calculating risk for. The answer is the loan, so that will be our second refactoring. We'll use the Rename Class refactoring, renaming the RiskCalculator to Loan. This becomes our first domain object in the system.

// RiskCalculator.cs has now become Loan.cs
public class Loan {
  // ...

  public string CalculateRisk() {
    // ...
  }
}

After each of these refactorings, the tests should be run and continue to pass. You can continue by cleaning up that awful business logic in the CalculateRisk method.

Now that our domain object is clean we could turn our attention back to that event handler, which should look something like this:

public void btnRate_click() {
  var Age = txtAge.Value;
  var Amount = txtAmount.Value;
  var HairColor = txtHairColor.Value;

  var Result = new Loan(Age, Amount, HairColor).CalculateRisk();

  lblResult.Value = Result;
}

I would probably clean this up by doing some Inline Temporary Variable and Extract Variable refactorings:

public void btnRate_click() {
  var MicroLoan = new Loan(txtAge.Value, txtAmount.Value, txtHairColor.Value);
  lblResult.Value = MicroLoan.CalculateRisk();
}

That's pretty clean now, and there's not really much code in there to mess up, so there's not much of a need for tests at this point.

Hope that helps. I didn't really answer your questions about repositories, but I am hoping that this gives you a path to get started on. When it comes to where to put your logic, keep the Single Responsibility Principle in mind, that will help you decide what goes in your repository and what doesn't. It also might cause you to break the Loan class into other smaller, more focused classes.

Good Luck! Brandon

score 1 · Answer 2 · edited May 23 '17 at 12:19

1

You could have a look at this existing questions:

Hope that helps.

edited May 23 '17 at 12:19

Community

1
1

answered Mar 12 '12 at 17:09

habakuk

2,712
2
28
47

score 1 · Accepted Answer · answered Mar 17 '12 at 03:45

Domain model pattern is quite fine if implemented not as static but as an instance methods. All you objects have its states and some specific behavior.

That's about where our domain logic should be. In this way unit testing can be written easy. You create an object with some state. Call method and verify if you expectations are met.

Persistence can be done with either ActiveRecord / Repository / DataMapper I don't really like ActiveRecord because it violates the single responsibility principle, but it's my own preference. There is a great discussion of each particular pattern in Fowler's EAA and here

To simplify I would go with some sort of already done solution like CastleActiveRecord or implement straightforward Repository. There is a great post on what repository can look like nowadays

So one option is to make your model containing your business logic. Implement repository / entity responsible for persistence. Forms should only represent your model. And controllers can serve user actions as there is only a finite set of them.

Just in case: data binding is a great feature of WinForms that allows to associate almost any data with controls with zero code.

If there are any restrictions that should be met by your architecture it can be a point of a discussion as each one has its own pros and cons. But MVC pattern is here with us since 80s' and its audience is only getting wider :)

score 1 · Answer 4 · answered Mar 17 '12 at 16:33

Windows Forms basic model allows a Code-Behind that binds data in and out of the UI controls. The Code-Behind is therefore not a good place to put any testable logic.

When I have done this (with ASP.NET Web Forms as well), I have always used Model-View-Presenter (MVP). This pattern is simple and separates concerns as much as possible. If you can, then choose WPF and go with MVVM. That will go further by allowing the UI to reactively handle rebinding.

Hope this helps.

score 0 · Answer 5 · answered Mar 03 '12 at 13:02

0

To make TDD easier, I suggest separating all the business logic into a separate class Library from the Windows forms Code. Don't write Tests for the Windows forms Code; keep the Winforms project free of any business logic. The class library should be fully covered with tests.

This has the benefit that you can write other interfaces than Winforms later, e.g. A command line interface or a web interface. And you could use a test tool like finesse to test the class library through its' public interface.

answered Mar 03 '12 at 13:02

GarethOwen

6,075
5
39
56

I plan on putting all the business logic in a class library, but I'm looking for suggestions on patterns or structures for doing that. At the worst end of the scale, I could have a public interface with just one big BusLog class, with static methods for everything. At the idealist end, I have several classes for each entity, command, etc. – ProfK Mar 03 '12 at 17:44

What basic architecture can I use for a single layer Windows Forms app?

5 Answers5