DevForce Community Forum : Cocktail/Temphire - Unit of Work & Repository Architecture

Cocktail/Temphire - Unit of Work & Repository Architecture : Yep, you got it. BTW, FindAll...

Wed, 06 Feb 2013 05:46:16 -700

Author: mgood
Subject: 3979
Posted: 06-Feb-2013 at 5:46am

Yep, you got it. BTW, FindAll would be a redundant method. This functionality is already provided by AllAsync().

Cocktail/Temphire - Unit of Work & Repository Architecture : Thank you for your reply. The...

Wed, 06 Feb 2013 01:37:07 -700

Author: DanielK
Subject: 3979
Posted: 06-Feb-2013 at 1:37am

Thank you for your reply.
The concept of interfaces is known but if working with demo applications it’s not always easy to understand if something was implemented just because for the sake of convenience.
However. If I understood you right. You recommend something like this, right?

Thanks
Daniel

namespace DomainServices.Repositories
{
    public interface IStaffingResourceRepository : IRepository
    {
        Task> FindAll();
    }
}

namespace DomainServices.Repositories
{
    public class StaffingResourceRepository : Repository, IStaffingResourceRepository
    {
        public StaffingResourceRepository(IEntityManagerProvider entityManagerProvider)
            : base(entityManagerProvider)
        {
        }

        public new TempHireEntities EntityManager
        {
            get { return (TempHireEntities) base.EntityManager; }
        }

        public Task> FindAll()
        {
            // Get all StaffingResources
            var query = EntityManager.StaffingResources;
            return query.ExecuteAsync();
        }

        protected override IEntityQuery GetKeyQuery(params object[] keyValues)
        {
            return EntityManager.StaffingResources
               .Where(r => r.Id == (Guid) keyValues[0])
               .Include(r => r.Addresses)
               .Include(r => r.PhoneNumbers);
        }
    }
}

namespace DomainServices
{
    public interface IResourceMgtUnitOfWork : IUnitOfWork
    {
        // Factories
        IFactory StaffingResourceFactory { get; }

        // Repositories
        IRepository AddressTypes { get; }
        IRepository States { get; }
        IRepository PhoneNumberTypes { get; }
        IRepository RateTypes { get; }
        IStaffingResourceRepository StaffingResources { get; }

        // Services
        IStaffingResourceSearchService Search { get; }
    }
}

Cocktail/Temphire - Unit of Work & Repository Architecture : Well, the point of an interface...

Tue, 05 Feb 2013 19:10:00 -700

Author: mgood
Subject: 3979
Posted: 05-Feb-2013 at 7:10pm

Well, the point of an interface is always the same. To define an abstract contract that allows for different implementations of said contract. For example for unit testing you can substitute the Cocktail implementation of the repository with a fake implementation that returns hard-coded data or you can easily replace an existing repository with an optimized implementation if you run into performance problems later in the lifecycle without having to change the parts of your application that interact with the repository. Interfaces are a pretty fundamental concept in modern programming languages.

If you don't like the contract that IRepository provides, then you simply create your own interface that either extends IRepository or completely replaces it.

Cocktail/Temphire - Unit of Work & Repository Architecture : I am just studying the Temphire...

Tue, 05 Feb 2013 14:53:04 -700

Author: DanielK
Subject: 3979
Posted: 05-Feb-2013 at 2:53pm

I am just studying the Temphire reference application and came across a topic I do not fully understand.
Maybe you can bring some light on the problem and recommend a best practice approach.

Let's say I would like to extend the StaffingResourceRepository by some custom data selection method, e.g.

public async Task> FindAll()
{
// Get all StaffingResources
var query = EntityManager.StaffingResources;
return await query.ExecuteAsync();
}

In the StaffingResourceDetailViewModel I would like to use this method but I can't because
in the ResourceMgtUnitOfWork the StaffingResources is defined as IRepository and not as StaffingResourceRepository.

Could you please explain why you use IRepository and not StaffingResourceRepository in the ResourceMgtUnitOfWork
and what is the best approach if I would like to use the "custom" StaffingResourceRepository in a ViewModel instead of the generic one.

Thank you for your assistance
Daniel