4

I am working on an enterprise application which will consist of a rich WPF client which talks to a bunch of webservices to retrieve data. This data are POCOs, created with Code First EF 4.2.

I am now facing a conceptual problem which i have been trying to wrap my head around but couldnt find a good solution to.

1:n Associations

So the datamodel looks like this:

public class Person
{
    public int Id { get; set; }
    public string Name { get; set; }
    public virtual ICollection<Person> Children { get; set; }
}

Serverside i have an interface which takes care of attaching newly create dtos (including new items in the Children Collection) from client side to the datacontext and saving it. This of course only works if those entities are created on the client side and then sent to be added. The service adds new entities and retursn the updated entities (Id property mainly) back.

[ServiceContract]
public interface IMyPersonCaretaker
{
    [OperationContract]
    Person CreatePerson(Person entity)
}

However when i am retrieving already existing entities i cannot edit any associations (add or remove entities - because they are of fixed size). So now i would need to expand the interface to allow this:

[ServiceContract]
public interface IMyPersonCaretaker
{
    [OperationContract]
    Person CreatePerson(Person entity)

    [OperationContract]
    Person AddChild(Person parent, Person child)
}

That to me seems a clumsy approach and the interfaces are getting bigger and bigger pretty fast. Is this the sophisticated approach of working with POCOs? How do you do it?

n:m Associations via manual Mapping

A different part of the datamodel looks like this:

public class ClassA
{
    public int Id { get; set; }
    public virtual ICollection<AtoBMapping> Mappings { get; set; }
}

public class ClassB
{
    public int Id { get; set; }
    public virtual ICollection<AtoBMapping> Mappings { get; set; }
}

public class AtoBMapping
{
    public int Id { get; set; }
    public virtual ClassA A { get; set; }
    public virtual ClassB B { get; set; }
}

Whenever i try to create an instance of ClassA and ClassB on the client side and add it to each other via a binding, i get an error when i try to add it to the Set in the context. The error says that it is not allowed to remove items from the Mappings property, and i dont really understand where this is coming from.

The second part might be a little bit too abstract description-wise, if someone needs further info, i am more than willing to add it!

PS: Please dont suggest Selftracking Entities, i know about them, but i would really be interested in a solution which is based purely on EF 4.2 POCOs.

PPS: The code is written by hand right into this window and not actual used code, so there might be stuff missing, but that is not the point of my question, so i hope it will suffice.

  • 1
    Could you expose a higher level abstraction as your service interface? I normally like to keep all my data model code inside the service and expose some sort of business logic operation on the service. So, instead of having methods like CreatePerson, AddChild, I might have something more closely resembling the action that is being performed in the software (hard for me to explain without knowing what you, ultimately, want the service to do, sorry!). – kmp Nov 22 '11 at 14:12
  • @user1039947 The ultimate target functionality is to manage data like the that - simple classes with a few 1:n assocs and fewer n:m assocs. Most of the time data is being added instead of edited. –  Nov 22 '11 at 14:31

1 Answers1

1

I have a similar solution where we need a whole bunch of CRUD type operations, but our datamodel does not leave the server, we map the objects to separate DTOs using automapper, these DTOs are generally the WCF DatContract classes and dont have as many relationships as a domain model.

Initially this might seem like a very verbose apprach, but IMO it eventually pays off because you have much explicit control over your interfaces, and in a lot of cases you dont really need to transfer the whole domain model (with all its relationships) to the client, a client can generally only display so much data.

another option might be WCF DataServices, they would use RESTful interfaces to transfer your data.

[New Option]

one other option i used in the past basically just one CRUD service methods that takes a byte array. Use NetDataContractSerializer to serialize/deserialize object graphs to and from those methods. Then use a custom client that tranfers data back and forth, create objects and attatch them to the DataContext to do operations.... something like this

np-hard
  • 5,725
  • 6
  • 52
  • 76
  • Thanks for your suggestion, ironically we just switched from using DTOs to POCOs because of the verbosity. I'd agree that its a better approach if you have that kind of complex datamodel, but ours is not, it is really simple. Still, even with DTOs you need to manage Parent Child assocs somewhere, somehow. –  Nov 22 '11 at 18:16