views:

61

answers:

1

Hello.

I am developing an piece of software where I have a few entities such as:

public class Workspace
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Description { get; set; }

        public virtual List<Playground> Playground { get; set; }
        public virtual List<Workspace> Children { get; set; }
        public virtual List<Member> Members { get; set; }

        public virtual Workspace Parent { get; set; }
    }   

public class Playground
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Description { get; set; }

        public virtual List<Service> Services { get; set; }

        public virtual Workspace Workspace { get; set; }
    }

public class Service
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Description { get; set; }

        public virtual Playground Playground { get; set; }
    }

These are my EF4 POCO objects. I am using the repository pattern and the following interface:

public interface IRepository<T>
{
    void Add(T entity);
    void Delete(T entity);
    IEnumerable<T> Get(Expression<Func<T, bool>> expression);
    IEnumerable<T> Get();
    void Attach(T entity);

    int Save();
}

The repositories have an internal ObjectContext. I have a UnitOfWork that contains instances of my repositories and is responsible to save the changes made to them.

Am i doing it right so far?

I am implementing a Business Logic Layer like this:

public class DomainWorkspaceService : DomainServiceBase
    {

        public DomainWorkspaceService(Workspace workspace)
            : base(UnitOfWorkFactory.GetInstance())
        {
        }

        public void Create(Workspace workspace)
        {
            UoW.GetRepository<Workspace>().Add(workspace);
        }

        public void Delete(Workspace workspace)
        {
            var pservice = new DomainPlaygroundService();
            foreach (var playground in workspace.Playground)
                pservice.Delete(playground);

            foreach (var child in workspace.Children)
                Delete(child);
        }

    }

Now i'm not sure i am going in the right direction. My POCOs are (will be) responsible for validation and will enable me to do something like

SomeWorkspace.Children.Add(new Workspace {...});

Since these objects are associated with a context, when i save them will the changes to the collections also be saved in the database?

Also, I want that my Playgrounds can't be created without a Workspace and Services without a Playground. Where should i create and delete them?

Thanks.

+1  A: 

So far, so good.

You probably want to move your Save method off of the Repository and onto the unit of work. In the Entity Framework, you have to save all changes in the context at once; you cannot do it per-type. Putting it on the Repository implies that only changes to the repository will be saved, which is probably not correct.

You might want to implement the cascade from workspace to playground as database cascades (which the Entity Framework will recognize and support) instead of manually coding them.

Yes, saving changes to the context will save all tracked changes, including related objects.

Regarding adding, if you don't expose the ObjectContext, then the only way that anyone will be able to add a Playground is via relationships with the objects you do expose.

Craig Stuntz
Yes, the Save is not supposed to be on the repository and i'll change the delete to cascade. Now i'm having trouble placing the creation methods (i need some extra processing when creating a (i.e.) service). Should they be places in a specific object, like the DomainWorkspaceService i added above? Thanks
codegarten
My rule of thumb is that the Repository is strictly to encapsulate persistence. If it's business logic, it goes in the service. If it's persistence-related (e.g., ID generation or something like that) it goes in the repository. The repository should be fairly simple.
Craig Stuntz