search

riskfirst / riskfirst.hateoas

Powerful HATEOAS functionality for .NET web api
MIT License
78 stars 25 forks source link

Suggestion for better decoupling/separation of concerns #31

Closed BenjaminCharlton closed 4 years ago

BenjaminCharlton commented 5 years ago

Thank you for writing this very helpful HATEOAS library. I have a suggestion that I think might improve it. Please let me know if you think it's a good idea.

Currently whatever library contains the data transfer objects (DTOs) that are used to pass representations of domain objects between the server and the client must have a dependency on RiskFirst.Hateoas. Furthermore, every DTO class must inherit from RiskFirst.Hateoas.Models.LinkContainer, and every collection of DTOs must be an ItemsLinkContainer.

It seems to me that this is not ideal. We might (at least hypthetically) want to reuse those same DTOs in another part of the application that deals clients that aren't RESTful or aren't even using HTTP...perhaps a Console client or WinForms or WPF or something else entriely.

Because DTOs are part of the core, maybe they shouldn't be tightly coupled to a library that specializes in HTTP communication. I was wondering if LinkContainer could become LinkContainer<T> where T is your DTO class, thus keeping DTO separate from the HATEOAS object. Something similar could be done with the collection class ItemsLinkContainer<T>.

What do you think... Is it possible? Is it a good idea? Could it be done without negatively affecting the output when the LinkContainer<T> is serialized to JSON?

jamiecoh commented 5 years ago

Hi,

The coupling-to-http problem is why this library was split into 2 packages

RiskFirst.Hateoas.Models only depends on newtonsoft.json which is usually ok for a DTO project. RiskFirst.Hateoas is what you would use for the REST api end, which has all the dependencies on http/web packages.

The dependency is actually only on an interface, so there's nothing stopping you implementing the functionality differently. If you wanted to write your own eg LinkContainer<T> it should be esy enough to do, and you can control exaactly how you want it serialized to JSON.

I'm not sure we would add this to the library itself, as (I think) we've provided everything you would need to implement this for your own project - but by all means if you think there is something that would benefit the library itself feel free to submit it as a pull request.

Thanks