dddpds Work Item Rss Feed

Closed Feature: Enhanced UnitOfWork Implementation [20739]

tmccart1 — Thu, 12 May 2011 06:23:35 GMT

Tim,

Your book has provided much inspiration and shown practical applications of Evan's work. The last few months has been really fun for me, and now my team is also starting to work with DDD and catching the bug, as well. I have made a modification to the UnitOfWork.cs implementation; actually it is mostly a rewrite. I wanted to share it with you and everyone else, in case in comes in handy.

The inspiration was that the UOW felt arbitrary, in the order that it actually persisted the entities. When starting to use (a modified version of) the code in the book, I ran into a couple of issues where I felt that the UOW would work better for my purposes if it was sequentially executed. I ran into this when I wanted to use a single UOW inside a Domain Service that coordinated calls between two different Repository implementations. The order that I needed some of the database operations to happen in were the same order by which the code called them.

So, this is what I came up with:

/// <summary>
/// Provides a distinct unit of work to be conducted for a type of entity.
/// </summary>
public sealed class UnitOfWork : IUnitOfWork
{
#region Constructors

/// <summary>
/// Initializes a new instance of the <see cref="UnitOfWork"/> class.
/// </summary>
public UnitOfWork()
{
this.Operations = new List<Operation>();
}

#endregion

#region Enumerations

/// <summary>
/// Provides the type of persistence operation to run.
/// </summary>
private enum OperationType
{
/// <summary>
/// Operation for an add.
/// </summary>
Add,

/// <summary>
/// Operation for a delete.
/// </summary>
Delete,

/// <summary>
/// Operation for an update.
/// </summary>
Update
}

#endregion

#region Private Property Declarations

/// <summary>
/// Gets or sets the operations.
/// </summary>
/// <value>The operations in this unit of work.</value>
private List<Operation> Operations { get; set; }

#endregion

#region Public Methods

/// <summary>
/// Commits all batched changes within the scope of a <see cref="TransactionScope" />.
/// </summary>
public void Commit()
{
using (var scope = new TransactionScope())
{
foreach (var operation in this.Operations.OrderBy(o => o.ProcessDate))
{
switch (operation.Type)
{
case OperationType.Add:
operation.Repository.PersistNewItem(operation.Entity);
break;
case OperationType.Delete:
operation.Repository.PersistDeletedItem(operation.Entity);
break;
case OperationType.Update:
operation.Repository.PersistUpdatedItem(operation.Entity);
break;
}
}

scope.Complete();
}

this.Operations.Clear();
}

/// <summary>
/// Registers an <see cref="IEntity" /> instance to be added through this <see cref="UnitOfWork" />.
/// </summary>
/// <param name="entity">The <see cref="IEntity" />.</param>
/// <param name="repository">The <see cref="IUnitOfWorkRepository" /> participating in the transaction.</param>
public void RegisterAdded(IEntity entity, IUnitOfWorkRepository repository)
{
this.Operations.Add(
new Operation
{
Entity = entity,
ProcessDate = DateTime.Now,
Repository = repository,
Type = OperationType.Add
});
}

/// <summary>
/// Registers an <see cref="IEntity" /> instance to be changed through this <see cref="UnitOfWork" />.
/// </summary>
/// <param name="entity">The <see cref="IEntity" />.</param>
/// <param name="repository">The <see cref="IUnitOfWorkRepository" /> participating in the transaction.</param>
public void RegisterChanged(IEntity entity, IUnitOfWorkRepository repository)
{
this.Operations.Add(
new Operation
{
Entity = entity,
ProcessDate = DateTime.Now,
Repository = repository,
Type = OperationType.Update
});
}

/// <summary>
/// Registers an <see cref="IEntity" /> instance to be deleted through this <see cref="UnitOfWork" />.
/// </summary>
/// <param name="entity">The <see cref="IEntity" />.</param>
/// <param name="repository">The <see cref="IUnitOfWorkRepository" /> participating in the transaction.</param>
public void RegisterDeleted(IEntity entity, IUnitOfWorkRepository repository)
{
this.Operations.Add(
new Operation
{
Entity = entity,
ProcessDate = DateTime.Now,
Repository = repository,
Type = OperationType.Delete
});
}

#endregion

/// <summary>
/// Provides a snapshot of an entity and the repository reference it belongs to.
/// </summary>
private sealed class Operation
{
/// <summary>
/// Gets or sets the entity.
/// </summary>
/// <value>The entity.</value>
public IEntity Entity { get; set; }

/// <summary>
/// Gets or sets the process date.
/// </summary>
/// <value>The process date.</value>
public DateTime ProcessDate { get; set; }

/// <summary>
/// Gets or sets the repository.
/// </summary>
/// <value>The repository.</value>
public IUnitOfWorkRepository Repository { get; set; }

/// <summary>
/// Gets or sets the type of operation.
/// </summary>
/// <value>The type of operation.</value>
public OperationType Type { get; set; }
}
}

The general concept is that instead of storing the three types of operations separately and going through the lists in a grouped order, I would contain them all with a single type of class, the private Operation class. It simply tracks the same information that the old Dictionary<> instances did, but adds a DateTime and an OperationType enumeration value. Instead of three loops (one for each of the previous operation type), it is replaced by a single loop with a switch() statement. The List<Operation> instance is just ordered by the DateTime and executed in order.

Two things are missing - well, one is missing, and one is my personal preference. The first, is that I don't have the ClientTransactionRepository implementation in here, as I had removed it from my local implementation. It should be very easy to add it back in, though. The second is that the UOW has an explicit Commit() method, but no explicit way to execute what is the UOW with an implied rollback (thinking about unit testing here, where I can still go through the queue but keep the database pristine to get beyond testing with mocks - but that is another story for another day.)

Anyhow, I hope that someone finds this useful. It is just nice to be able to give something back.

Thanks!

Joseph
Comments: Resolved with changeset 60703.

Created Feature: Enhanced UnitOfWork Implementation [20739]

tmccart1 — Thu, 12 May 2011 06:11:04 GMT

Commented Issue: Entity equality does not work in all cases [20736]

tmccart1 — Thu, 12 May 2011 05:36:22 GMT

Hi Tim,

I have come across a very subtle bug in the EntityBase == operator overload method in the following statement:

if (base1.Key != base2.Key)

This does not work if the base1.Key and base2.Key properties don't reference the same Guid object, but have the same value. The statement does work if both Key properties reference the same Guid object. The fix for this bug is to replace the statement with this one:

if (base1.Key.Equals(base2.Key))

This second statement works fine in all cases. The reason for this has to do with the fact that the == and != operator overloads are not virtual whereas the Equals method is virtual. So, what happens in the first statement is that the != operator overload for the System.Object class is called and not the overload defined in the Guid class, since the Key property is declared as type object. This causes a reference comparison and not a value comparison. A value comparison is what is needed for this operator overload to work as needed. The second statement will cause the Equals method of the Guid struct to be called and not the one defined for the System.Object class, since it is virtual, and the correct value comparison between the two Guids is done, instead of a reference comparison.

Here is a unit test that demonstrates the issue:

public void EntitiesAreEqualIfDifferentEntityAndKeyObjectsButSameKeyValue()

{

EntityBase entity1 = new EntityBase();

Guid id2 = new Guid(entity1.Key.ToString());

EntityBase entity2 = new EntityBase(id2);

Assert.AreEqual(entity1.Key, entity2.Key);

Assert.AreEqual(entity1, entity2);

Assert.IsTrue(entity1.Equals(entity2));

Assert.IsTrue(entity1 == entity2);

Assert.IsFalse(entity1 != entity2);

}

This unit test will fail on the second Assert. When I change the EntityBase == operator overload method with the new statement above, this unit test passes.
Comments: ** Comment from web user: tmccart1 **

Thanks for finding that rkanagy!

Closed Issue: Entity equality does not work in all cases [20736]

tmccart1 — Thu, 12 May 2011 05:35:32 GMT

Created Issue: Entity equality does not work in all cases [20736]

tmccart1 — Thu, 12 May 2011 05:17:08 GMT

Closed Feature: Update code base to use Entity Framework [10966]

tmccart1 — Thu, 12 May 2011 05:13:48 GMT

I would like to see EF being incorporated into the code.

Thanks
Rad
Comments:

I have decided not to implement this feature.

Commented Feature: Update code base to use Entity Framework [10966]

tmccart1 — Thu, 12 May 2011 05:13:21 GMT

I would like to see EF being incorporated into the code.

Thanks
Rad
Comments: ** Comment from web user: tmccart1 **

Ideally, EF would only need to be implemented in the respositories, but due to its current design, it would also end up changing some of the Entity classes.

Closed Issue: Correction to ToClientMembershipUser [11416]

tmccart1 — Thu, 12 May 2011 05:09:03 GMT

Picked up a mistaking in the Converter.ToClientMembershipUser() method on line 1043 (as per changeset 18409).
The "if" test should be a null check against the "contract" parameter, and not the "user" local variable.

Enjoying the book!
Thanks
Comments: Resolved with changeset 60700.

Commented Issue: Update code base to use Entity Framework [10966]

tmccart1 — Thu, 12 May 2011 05:01:41 GMT

I would like to see EF being incorporated into the code.

Thanks
Rad
Comments: ** Comment from web user: tmccart1 **

I personally do not like EF and think that it adds too much baggage to the classes, although the latest version of EF is getting better with code-first design.

Closed Issue: gather all reusable code of this sample into a single project... [13220]

tmccart1 — Mon, 07 Feb 2011 22:56:16 GMT

Great work and Great book. It would be even greater if you gather all reusable assets into a single project
Comments:

This is done now...all code is .NET 4.0 and no more external references to the Xceed data grid.

Commented Issue: Update code base to use Entity Framework [10966]

MarioMajcica — Tue, 13 Oct 2009 09:47:11 GMT

I would like to see EF being incorporated into the code.

Thanks
Rad
Comments: ** Comment from web user: MarioMajcica **

Even I am interested on how to "fill in" EF?

Thanks

Created Issue: gather all reusable code of this sample into a single project...

cbakopanos — Tue, 12 May 2009 20:39:37 GMT

Great work and Great book. It would be even greater if you gather all reusable assets into a single project

Created Issue: Correction to ToClientMembershipUser

chrisstefano — Mon, 06 Oct 2008 22:10:33 GMT

Created Issue: design and implement a entity key class

BerrylHesh — Wed, 13 Aug 2008 02:35:16 GMT

This would replace the current key property in the Entity base class, and be responsible for maintaining the value that defines the Entity's identity in a type safe way (types should include guid and long) that is easily accessible to sql strings without requiring casting.

Created Issue: Update code base to use Entity Framework

raca — Sun, 10 Aug 2008 20:04:02 GMT

I would like to see EF being incorporated into the code.

Thanks
Rad

Created Issue: Update code base to use Enterprise Library 4.0

tmccart1 — Tue, 24 Jun 2008 21:51:39 GMT

The current code base is using EntLib 3.0 and needs to be upgraded to 4.0.

CLOSED ISSUE: Sanity check in EntityBase.GetHashCode()

tmccart1 — Mon, 05 May 2008 17:06:33 GMT

Hi,

You should really check for key != null before invoking its GetHashCode().

Regards,

Lars Wilhelmsen

CREATED ISSUE: [Suggestion] Use the Converter delegate for entity translators

larsw — Sun, 04 May 2008 12:58:30 GMT

Hi,

In SmartCA.DataContracts.Helpers.Converter.cs static TOXxx(...) methods are used to translate the entities to data contract instances.

I suggest that you use the Converter<TInput, TOutput> delegate instead, since this is also very useful with the new extension method ConvertAll() on System.Array.

Regards

Lars Wilhelmsen

CREATED ISSUE: Sanity check in EntityBase.GetHashCode()

larsw — Sun, 04 May 2008 06:40:58 GMT

Hi,

You should really check for key != null before invoking its GetHashCode().

Regards,

Lars Wilhelmsen

CLOSED ISSUE: Source Zip 14557 and 14530 error on extract

tmccart1 — Thu, 06 Mar 2008 23:38:42 GMT

Tim, I tried to extract changesets 14557 and 14530. With both I ran into an issue that says "There is already a folder with the same name as the filen name you specified. SmartCA, file type folder. I you Open the zip there is a SmartCA folder and second SmartCA file / folder.

The folders that do get extracted look like they have the entire project. So I am not sure what the second "folder" contains.

Thanks
ScooterDude