0

I'm starting a new asp.net mvc core project and for my infrastructure layer I'd like to use WebAPI as this layer should be usable in other solutions besides this one.

I'm not really experienced with that and at the moment I'm thinking of having 2 contracts and 2 implementations for them in the infrastructure layer e.g:

public interface IUserService
{
    int Add(UserDTO user);
    UserDTO Update(UserDTO user);
    UserDTO Remove(UserDTO user);
    UserDTO Get(int id);
}

public interface IUserWebService
{
    int Add(UserDTO user);
    UserDTO Update(UserDTO user);
    UserDTO Remove(UserDTO user);
    UserDTO Get(int id);
}

Where the first one is the one that will be injected in the controllers in the presentation layer and the second one is the one that will be implemented by the WebAPI.

Then the implementation goes like this, the web api simply implements the IUserWebService along with the crud operations just as usual and then another type is created UserService which implements IUserService, which will serve only as a wrapper for the webapi implementation. The reason being invoking the webapi is a bit lengthy and this way that part of the logic will be isolated in this extra class.

This seems reasonable to me, but I'm not sure if it's the proper way to go, any advises would be welcome.

1

I don't think there is anything intrinsically wrong with anything you've stated. If I were to make some recommendations they would be the following, in no particular order.

  1. Structure the service contract around your workflow, not around CRUD operations. It's easy to write CRUD services, but they are seldom what you want long term. Take user create, for example. It is very rare to create a record for a user and that's it. Is there a signup flow? What steps are there? Structure the service contract around that.
  2. Interfaces are a wonderful tool, but only create them where you know there will be multiple implementations. If you only know about one implementation, write the class and be mindful of public/private modifiers. You can extract the interface later if you discover that multiple implementations are possible. This keeps your code simpler and easier to follow.
  3. WebAPI is a wonderful tool for building HTTP based systems. It is flexible to write either RPC or REST style interfaces, so spend a little time to determine which one you want to build and stay consistent with it.
| improve this answer | |
  • Thank you for your answer, could you elaborate a bit on the first part? How would that affect the service structure? – Deadzone Nov 11 '19 at 18:38
  • As for the interfaces, even if only 1 implementation is present, you always get the benefit of later substitution the specific types to test them more easily. – Deadzone Nov 12 '19 at 5:41
  • On the first bit, it would change the methods you have in your service contract. Instead of CreateUser maybe there's RegisterUser which accepts the data a user would fill out in the form and returns what a client would need to surface results to the user. What happens with a lot of CRUD services is that the real business logic and validation end up getting shunted onto consumers of the web service, with the "right" way to call a service being tribal knowledge. – Michael Nov 12 '19 at 18:28
  • For interfaces, it can work to create them in advance without any knowledge of whether there will be multiple implementations and that was pretty common for a time. hat you end up having is more clutter which puts cognitive burden on the readers of the code. Burden that, if there aren't multiple implementations, may never pay off. Or, perhaps more simply, it's an invocation of YAGNI. – Michael Nov 12 '19 at 18:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.