jeudi 27 octobre 2016

Design pattern for storing customer specific requirements

tldr; Looking for a design pattern that is good at handling a variety of requirements customers have on database fields.

Been looking and have not come across anyone with a similar issue, but if I missed one please let me know! Also, I suspect I may be either over-complicating the issue, or trying to do too much at once. Sorry for the wall of text incoming.

Okay, so I am designing a new application in C# for a company I have worked with in the past. I am writing this application to replace the VB6 application they have in place now. This new application's scope will be for the initial information gathering phase.

The company is for roadside assistance; trucks breaking down for companies with big rig trucks. They assist hundreds of customers, and each customer has its own requirements. The company bends over backwards for each customer, and therefore I need to come up with a manageable design to handle these customer specifications. All previously developed applications had in-line "if else" logic for literally hundreds of customers and I still have nightmares about it.

Example:

A user will take a phone call from a customer and collect information, which they input into this application. They will be calling to report an event such as a flat tire. Sometimes the person calling in is the driver. Other times the driver has called the company they work for, and a representative calls to report the incident and request help. Let's focus on a few pieces of information so I may paint the picture.

  1. Customer Reference Number
  2. Odometer
  3. List item

Not every customer requires a reference number. Some customers require a reference number adhere to a certain mask, for example "Reference Number must start with BD-XXX-XXXX-XX" or something similar. Other customers don't even have reference numbers, so there is no point capturing this data (it doesn't exist).

Some customers require an odometer reading of the mileage, some don't.

So you might begin to see my issue. Customer A doesn't need a reference number. Customer B needs a reference number. It's not as simple as NOT NULL vs NULL though, because B also needs their reference number to match an input mask.

Types of requirements:

  • Field value must be Greater than/Less than X
  • Field must adhere to Input Mask
  • Field Not collected at all
  • Field Required
  • Field Optional
  • Field value dictates whether other information must be/must not be collected. If one specific field is null, another becomes required

I would like to store customer requirements in the database (SQL) and perhaps be able to load a class with this data that will be able to handle the requirements for the UI portion of the application.

Components of the project are required to be: C# Windows app WCF Service for data (will be used between multiple applications & web) SQL Server 2012

Aucun commentaire:

Enregistrer un commentaire