0

I know that there are already a couple of answers about this but I just don't want to start on the wrong foot. My POCOs have inheritance and interfaces to work in my Repository which I think is the standard way to use the repository pattern right? So from what I read, I should have my POCOs duplicated into DTOs in order to use them in my Service? Really?

Is that what they say when they talk about the overhead of using DTOs?

I realize that the "Simple Customer Database REST Services Example" is well...simple but still, it sends back the POCO. If the customer would have a lot of properties and you would want to create it, is the CreateCustomer DTO would have to have the same properties as the customer POCO? And when you would respond to GetCustomer, you could not return the POCO if it would have interface/inheritance.

Maybe I just don't get it...seems a lot of work.

jbrabant
  • 245
  • 4
  • 11

1 Answers1

2

It's hard to provide clear answers as you're not really asking clear questions or providing concrete examples illustrating your concerns.

It also sounds like a lot of what you want to do are discouraged practices, I'd recommend adjusting your perception on what is work as the short-cuts you want to do are likely going to cause you issues down the road.

You can re-use POCO Data Models as DTO's

If you're using code-first POCO ORM like OrmLite you can re-use a lot of your Data Models as DTO's, but they should be maintained in the ServiceModel project (aka DTO .dll). You should maintain a separate DTO when your internal data model and external service contracts diverge, at which point you can use the built-in AutoMapping to easily convert between them.

The Service Layer is your most important Contract

You do not want to re-use your Request DTO for anything other than defining your external service contract - your most important contract. It is by nature an operation that's ideally grouped by call semantics and Response Types where as your Data Models are typically nouns that have nothing to do with the operation that operates them.

You should think of using POCO classes defining your Request DTO's as a DSL where its properties are providing a clear source of reference describing explicitly what your Service accepts/returns. POCO's are declarative, hiding them behind inheritance is adding indirection, blurring concerns and reducing clarity, I wouldn't think of it as saving work.

Interfaces and Inheritance in DTO's is bad practice

Whilst interface (or base class) properties allow for loose-coupling in code they have the opposite effect when serialized which require proprietary serialization extensions and coupling to .NET namespaces, reducing Interoperability - one of the core goals of Services. They're also likely going to lead to runtime errors in future.

Community
  • 1
  • 1
mythz
  • 141,670
  • 29
  • 246
  • 390
  • Thanks Mythz, it answers my question. When you say discouraged practices, are you referring to Repository Pattern? I know I did not provide any details of what I want to do but if you can point me to the right direction when comes time to use those Repository/Unit of Work stuff, it would be helpful. Thanks again. – jbrabant Nov 23 '15 at 14:28
  • @jbrabant no not talking about Repository/UoW which is an internal impl detail that doesn't affect the service layer. – mythz Nov 23 '15 at 16:30