Do I need to use state pattern for data approval process?

Users of our system are able to submit un-validated contact data. For example:

• Forename: null
• Surname: 231
• TelephoneNumber: not sure
• etc

This data is stored in a PendingContacts table.

I have another table - ApprovedContacts. This table has a variety of constraints to improve consistency and integrity. This table shouldn't contain any dirty or incomplete data.

I need a process to move data from one table to another. Structure of both tables is nearly identical, however, one table has the constraints, when another doesn't.

I have two states: Pending and Approved, gut feeling tells me that I should use a state pattern details here. In theory this should allow me to change contact's state from Pending to Approved, depending on whether the contact has been successfully validated. Problem is that I don't see how is this going to work.

Am I going in a right direction or should I be looking at something completely different?

Presentation layer is in MVC 3, so I have view models for pending contacts and approved contacts, as well as domain models for pending contacts and approved contacts. My view models are generally DTOs with some validation routines, but now my view models represent state too. This doesn't seem right.

For example, all contacts must have a state and they can be saved and removed , so I need an interface for that:

public interface IContactViewModelState
{        
    void Save(ContactViewModel item);
}

I then add an implementation for saving pending co开发者_运维百科ntacts into the PendingContacts table:

public class PendingContactViewModelState: IContactViewModelState
{
    public void Save(ContactViewModel item)
    {
        // Save to the pending contacts table
        // I don't like this as my view model now references data access layer 
    }
}

Short answer: no, because you only have two states. You'd use a state pattern to help deal with complex situations with many states and rules. The only reason you might want to go with a full-blown state pattern based implementation is if you there's a very high chance such a situation is imminent.

If the result of a success transition to Approved is the record ending up in the approved table then you really just need to decide where you want to enforce the constraints. This decision will/can be based on many factors including the likely frequency of change (to the constraints) and where other logic resides.

A lot of patterns (but not all) tend to deal with how to structure an application, but here I think it's just a case of deciding where and how implementing some logic. In other words - you might just be accidentally over-analyzing the problem - it's easily done :)