CODEWITHSUNDEEP
c#wcfarchitecture
Annie
Annie

Reputation: 672

wcf service and asp .net presentation layer

I have wcf service which is responsible for database interaction and business logic. it also has class library for business objects. i want wcf service to return List of objects. should i have to create another class lib of business objects for my asp .net project(which is consuming service) so that asp .net project can understand the object types?

Upvotes: 0

Views: 794

Answers (3)

Filippo Pensalfini
Filippo Pensalfini

Reputation: 1714

Standard practice with services is to return DTOs instead of business objects: using your business objects in the presentation layer is going to tightly couple it to the business logic, and most of the time you don't want this sort of coupling. Also bear in mind that everything that you send on the wire should be serializable, and your business objects may or may not be serializable.

So I would say that yes, you most probably want to create a different library with DTOs and use the classes inside it as data contracts. The duplication is not really a problem, since it guarantees a certain stability of the contract and it is possible to map your business objects to DTOs with tools like AutoMapper.

Let us consider the advantages and disadvantages of the approach of having a common business class library shared between presentation (ASP.NET) and service layer.

Pros:

  • easy to implement: just wire up the existing project to the asp.net, mark your classes as serializable and you're done
  • non-redundant: you have one class to represent a concept

Cons:

  • your classes may not be serializable
  • it is very easy to "slip" and use a business class which you are not supposed to use in your presentation layer directly without going through the service
  • tight coupling: change the business classes and both service and presentation layer may break
  • why are we using services again?

Compare this to the creation of a DTO library:

Pros:

  • the interface (data contracts) is well defined: everything that is in this library is a communication object
  • no problems with serialization
  • loose coupling between presentation and services: with the help of the abstraction of data contracts, changes in the business logic reflect at most up to the DTO mapping level

Cons:

  • you need to map your objects to a DTOs (thought AutoMapper is really helpful with this)
  • Dmitriy cited duplication, though unnecessary is subjective: I think I showed you why there is a need for it. Besides, you should not be scared to introduce different views of the same concept for consumption in different parts of your application: I have yet to find a model which perfectly fits every use case in nontrivial programs.

Upvotes: 1

Dmitry Reznik
Dmitry Reznik

Reputation: 6862

You should share the class object library between the service and the asp.net project. That would be like 'middleware' for your whole project. That would avoid unnecessary duplication. Basically, just move all business objects to a different project and include it into both wcf and asp.net solutions.

Upvotes: 2

Habib
Habib

Reputation: 223307

Not really. When you will add the reference to web service using Add Service Reference via visual studio, you will get proxy classes for every object to be used in the web service

Upvotes: 1

Related Questions