-1

So I'm working on a new MVC project and all data access will be through a web service. I want to put the service reference and web service calls in a sort of data layer in a separate class library project. Now my dilemma is since the "entities" (members) will be coming from the web service, the main web project will need to reference the web service object and then the entities through that object. I want to stay away from that approach to limit the main project's access to the web service by creating a class for each entity on the data layer that which inherits the corresponding entity from the web service. This of course sorts of duplicates the classes (from my project and the web service). But can also be a way to extend functionality from my project - but not all classes will need extensibility and redundancy comes into play. Now is there any better approach to this? I just want to limit the dependency from the web service.

whastupduck
  • 200
  • 1
  • 11
  • 2
    Possible duplicate of [Choosing the right Design Pattern](https://softwareengineering.stackexchange.com/questions/227868/choosing-the-right-design-pattern) – gnat Aug 08 '17 at 19:06
  • Just add a layer of indirection between your data layer and your web project. Generally this would be considered a Service Layer or Business Logic Layer. – Robert Harvey Aug 08 '17 at 19:44
  • What's the actual problem you're trying to solve? Are you just looking to avoid referencing the web service assembly from your MVC project for some POCO models? – Ben Cottrell Aug 08 '17 at 20:00

2 Answers2

2

I would create a common model that you can use in both your client and server. You can distribute these models in a separate package so that client doesn't directly depend on the service's code. 

client -> models
service -> models

If you duplicate the classes in the client that are defined in the service, then you're likely to have bugs from differences in model, and it will be more work to maintain both models.

Samuel
  • 9,137
  • 1
  • 25
  • 42
2

I want to stay away from that approach to limit the main project's access to the web service by creating a class for each entity on the data layer that which inherits the corresponding entity from the web service.

I wouldn't do that, and you can't anyway-- if a library's class inherits from another class in that library, both classes must be public.

Instead, I would do it this way

  1. Forget the web service exists.
  2. Define a domain model that the caller of your service will find most suitable to the problem at hand.
  3. Write code to map between the web service classes and the domain model.

Note that there might not be a 1:1 mapping; for example, the caller of your library might want to work with a single User class while under the covers it maps to a UserDetails and UserPermissions class exposed by the web service. Or the reverse might be true, e.g. the service exposes a giant Everything class and the domain model exposes that in two or more classes that make sense for the caller to work with.

By the way, this sort of thing is common-- don't feel like you're doing something "wrong" by writing two layers of classes. The job of the library is to consolidate and simplify the underlying complexity of the web service; this is a Good Thing.

John Wu
  • 26,032
  • 10
  • 63
  • 84