0

I've run into a rather annoying issue when dealing with auto generated classes that's part of the domain model.

For example I'm consuming an OData endpoint which has entities that's part of my core domain model. I'm using the OData v4 Client Code Generator tool which is great but it outputs something like this:

public partial class FooBar :
    global::Microsoft.OData.Client.BaseEntityType,
    global::System.ComponentModel.INotifyPropertyChanged
{
    ...

That's tightly coupled to the Microsoft.OData.Client which doesn't belong in the domain model.

One way to fix this would be to keep the auto-generated FooBar class in a Microsoft.OData.Client infrastructure project and create my own POCO of FooBar in the DomainModel project and then use AutoMapper to map between them. But that's so cumbersome :(

I much prefer the way Entity Framework does it via POCOs in the Code First approach. But I don't suppose that would be easy to implement elsewhere.

I'm at a loss here. I'd like to know what you've done when working with problems like this. Have I missed something obvious? Any (helpful) input really :)

Snæbjørn
  • 10,322
  • 14
  • 65
  • 124
  • What is your specific concern? You are using an OData entity class. Of _course_ it has dependencies on OData. Perhaps you should not be using an entity class, but instead working against an interface? – John Saunders Mar 24 '15 at 20:44
  • I guess my concern is how you best abstract the interaction with external resources like OData or WCF while still being able to take advantage of the auto-generated classes in your core domain model. – Snæbjørn Mar 24 '15 at 20:58
  • 1
    I believe you're misunderstanding the tool. It is not a tool that generates POCO classes corresponding to an OData service. It intends to generate an "OData Client" for that service. Now, perhaps you could use it as the basis for a set of POCO classes by modifying the T4 template, but the tool has no intention of doing what you're asking. – John Saunders Mar 24 '15 at 21:16
  • That would actually explain a lot – Snæbjørn Mar 24 '15 at 21:20
  • So I guess I'm left with the `AutoMapper` way – Snæbjørn Mar 24 '15 at 21:31
  • I haven't used OData, but in similar situations (WCF), I typically have a set of Data Transfer Object classes (pretty much just POCO), in a separate project, then use the "Share Types" feature of "Add Service Reference" or the equivalent so that the WCF client reads and writes objects of those types. I will likely then have ViewModel classes, and will use AutoMapper to map between them. You get complete separation, except in the code that needs to manipulate both kinds of class. Same in the service between, say DTO and Entity Framework classes. – John Saunders Mar 24 '15 at 21:44
  • Didn't know about the "Share Types" function. I'll need to look into that. Your input is very helpful :) – Snæbjørn Mar 24 '15 at 21:53

0 Answers0