backgroundmotion Forum Rss Feed

New Post: UnitOfWork static gateway

bfcamara — Fri, 03 Oct 2008 15:26:59 GMT

Hi,

I am checking the code in the UnitOfWork class, which is is a static gateway to the current UnifOfWork instance. However, it is something that i can' understant the intention.

The implementation of UnitOfWork.Complete is

    public static void Complete()
    {
      Current.Complete();
    }

and the Current property is

    private static IUnitOfWork Current
    {
      get { return GetCurrent<IUnitOfWork>(); }
    }

where the GetCurrent

    public static T GetCurrent<T>()
      where T : IUnitOfWork
    {
      return ContextItemsBroker.GetItem<T>(CurrentContextKey);
    }

The CuurentContextKey is based on the private field _depth, which is a static field. First of all, there is no sycnhronization in this field, which is static. Interlock.Increment/Decrement would be more safe? When you have this code

using (UnitOfWork.Begin())
      {
        contribution = UnmoderatedContributions
          .Where(c => c.Id == id)
          .SingleOrDefault();

        if (contribution != null)
        {
          contribution.ApprovedBy = CurrentMember;
          Repository<Contribution>.Save(contribution);
          UnitOfWork.Complete();
        }
      }

The UnitOfWork.Complete can be call a Complete in a UnitOfWork which is not the one returned in the Begin method. Is it supposed to be like this?

Thanks in advance

BFC

NEW POST: Repository implementation

RBisch — Mon, 09 Jun 2008 05:14:22 GMT

Henrik,
Just want to preface this post with the following statement: "It's a shame there are so many orphaned CodePlex projects". - end of grip.

Ok, as I am not the original author, I can only make assumptions in my attempt to answer your questions.

Regarding your questions (3,4); I believe the implementation of the Repository pattern is taking advantage of LINQ in the sense that, the repository interface is easily
implemented due to LINQ functionality. In essence the Repository code in this project is just a light wrapper around LINQ generated classes. Therefore, it is more of a
generic implementation. Nothing has to extend the standard Repository methods, as the IRepository is a fully defined interface to provide all necessary functionality to
fulfill the duties of a Repository.

I think what you are seeking is an implementation base more on logic than a generic one that is used in this project. You might want to take a look at the code here:
http://www.codeplex.com/mvcsamples , it uses more of a logical based approach.

- Good luck.

firefajter wrote:
3. Have you considered a way of dealing with multiple repostiories at the same time?
4. How would you suggest handling a specialized repository, for example a CustomerRepository extending the standard Repository methods.

Thanks in advance
/Henrik

NEW POST: Repository implementation

firefajter — Wed, 26 Mar 2008 15:00:46 GMT

Hi, i've started to look att your implementation of repository/unit of work pattern for background motion and it seems great way of doing this. I want to use a similiar thing using the entity framework and have some questions that maybe you can help me answer.

1. Since this was designed a year ago, is there anything you learned during this time of what worked out and if there is something you would have done differently today?
2. Do you see any big problems of using this with entity framework (execept from the fact that model objects has to inherit from EntityObject)
3. Have you considered a way of dealing with multiple repostiories at the same time?
4. How would you suggest handling a specialized repository, for example a CustomerRepository extending the standard Repository methods.

Thanks in advance
/Henrik