I have seen a particular pattern a few times over the last few years. Please let me describe it.

In the UI, each new record (e.g., new customers details) is stored on the form without saving to database. This clearly has been done so not clutter the database or cause unnecessary database hits.

While in the UI state, these objects are identified using a Guid. When these are a saved to the database, their associated Guids are not stored. Instead, they are assigned a database Int as their primary key.

The form can cope with a mixure of retrieved items from the database (using Int) as well as those that have not yet been committed (using Guid).

When inspecting the form (using Firebug) to see which key was used, we found a two part delimited combined key had been used. The first part is a guid (an empty guid if drawn from the database) and t开发者_StackOverflowhe second part is the integer (zero is stored if it is not drawn from the database). As one part of the combined key will always uniquely identify a record, it works rather well.

Is this Good practice or not? Can anyone tell me the pattern name or suggest one if it is not already named?

There are a couple patterns at play here.

Identity Field Pattern

Defined in P of EAA as "Saves a database ID field in an object to maintain identity between an in-memory object and a database row." This part is obvious.

Transaction Script and Metadata Mapping

In general, the ASP.NET DataBound controls use something like an Transaction Script pattern in conjunction with a Metadata Mapping pattern. Fowler defines Metadata Mapping as "holding details of object-relational mapping in metadata". If you have ever written a data source control, the Metadata Mapping aspect of this pattern seems obvious.

The Transaction Script pattern "organizes business logic by procedures where each procedure handles a single request from the presentation." In order to encapsulate the logic of maintaining both presentation state and data-state it is necessary for the intermediary object to indicate:

1. If a database record exists
2. How to identify the backend data record, to populate the UI control
3. How to identify the data and the UI control if there is no current data record, so that presentation data can be updated from the backend datastore.

The presence of the new client data entry Guid and the data-record integer Id provide adequate information to determine all of this with only a single call to the database. This could be accomplished by just using integers (and perhaps giving a unique negative integer for each unpersisted UI data item), but it is probably more explicit to have two separate fields.

Good or Bad Practice?

It depends. ASP.NET is a pretty successful software project, and this pattern seems to work consistently. However, this type of ASP.NET web control has a very specific scope of application - to encapsulate interaction between a UI and a database about data objects with simple mappings. The concerns do seem a little blurred, but for many applicable scenarios this will still be acceptable. The pattern is valid whereever a Row Data Gateway would be acceptable. If there is more than one database row affected by a web control, then this approach will not be functional. In these more complex cases, either an Active Record implementation or the combination of a Domain Model and a Repository implementation would be better suited.

Whether a pattern is good or bad practice really depends on the scenario in which it is being applied. It seems like people tend to advocate more complex design structures, because they can be applied to more scenarios without failing. However, in a very simple application where the mappings between data records and the UI are direct, this pattern is very useful because it creates the intended result while minimizing the amount of performance and development overhead.

I don't think there is a specific pattern for that.

Is it good practice? I don't think so. First, it's not very object oriented. How about:

interface ICommittable
{
    /// <summary>
    /// Gets or sets a value indicating whether the entity was already committed to the database.
    /// </summary>
    bool IsCommitted;

    /// <summary>
    /// Gets or sets the ID of the entity, used either in database or generated by UI or an underlying BL.
    /// </summary>
    Guid Id;
}

Instead, what they do is to mix three separate data entries in one in a non obvious way:

• The ID
• Another ID (why?)
• A fact that the entity was committed or not.

Especially, having two separate IDs is extremely confusing and will require not only a good documentation, but some time for a new developer to understand what's happening here.

If the purpose was to create new entities without querying the database for a new ID, they could use GUIDs everywhere: when a new entity is created, you Guid.CreateNew it's ID, then, if need, you commit everything, this GUID being the identifier in the database too (there are few chances to have a collision between already saved GUIDs and a new one, so I wouldn't care about that).

Much more simple, isn't it?

It's also not easy to do a few things. For example, how do you compare two entities? Remember that:

• Two committed entities which have different GUIDs are not equal,
• Two not committed entities which have different IDs are not equal,
• A committed entity may be equal to a non committed entity, even if their GUIDs and their IDs will be different.

To conclude, it seems like a lack of refactoring. Probably they were modifying a project where entities were already identified in the database by their id (int) unique key, so instead of refactoring this, they just added GUIDs, thus making the overall thing:

• More difficult to understand,
• Very difficult to work with and to modify in future.

If I'm not wrong it's the repository pattern: http://martinfowler.com/eaaCatalog/repository.html

This is well described in the Evans Domain Driven Design book and has proven to work well under specific circumstances.