Geeks With Blogs
Mike Nichols - SonOfNun Technology If I were the captain on a big steamboat...
So a simple design question to get feedback about what folks think regarding ASP.NET usage of a Service Layer. In an application (non-distributed web app) that wants to implement a Service Layer to provide a simple API for a relatively complex business logic layer, there seem to be two options for communicating data from those clients...in our case a web page.
In the code-behind, we can grab the values from webcontrols and send those primitive types directly to the service layer methods - our basic CRUD functions. It becomes obvious that some methods are going to have a heavy load of parameters so the developer guy gets lazy and just performs the operations directly in the code-behind on the business objects themselves, short-circuiting the Service Layer.
He's heard about Data Transfer Objects DTO, but thought they would be redundant and would always seem to be in a one-to-one relationship with the Domain Objects...so why not just use the Domain Objects directly? Of course, Domain Objects are going to often have complex types as opposed to the DTO's having (usually) just primitive types...following the idea that the Domain maintains entity relationships (not DTO's).
So the purist says "let's do DTO's" and the lazy coder says "it's easier to just hydrate and perform actions on the Domain directly from teh code-behind". So do more folks do a combination of both, only utilizing DTO's when the parameter abundance is overwhelming and makes the code look sloppy?
Naturally, you have to go into java sites/forums to find any serious discussion about these kinds of questions and that was very helpful,but I thot I'd ellicit feedback from ASP.NET folks who have wanted to implement a service layer and keep all domain logic-method calls out of the code-behinds.
It seems overkill to use DTO's between the application logic (service layers) and domain logic (domain layer) in a app that will never be distributed. But DTO's would seem to clean-up all the parameter passing between control values/code-behind and the service layer they will eventually impact. Posted on Monday, June 12, 2006 10:02 PM General | Back to top


Comments on this post: Presentation to Service Layer - to DTO or not in ASP.NET?

# re: Presentation to Service Layer - to DTO or not in ASP.NET?
Requesting Gravatar...
hi mike

i agreee with u on this..i did some searching on google on this topic and also tried it out on a project..we did noot use DTO's betw service layer and domain model, but it made our code look messy..:-)..so if any1 asks me..i advise them to go for DTO..it pays in the long run...also..i use same DTOs between DAL and BLL. let me knw wat u think of this.
Left by vivek on Jun 13, 2006 9:57 AM

# re: Presentation to Service Layer - to DTO or not in ASP.NET?
Requesting Gravatar...
hi Mike,

i agree with u..nice posts!

Left by vivek on Jun 13, 2006 10:45 PM

# re: Presentation to Service Layer - to DTO or not in ASP.NET?
Requesting Gravatar...
We've recently started using DTO's.

The main problems were:

- Nhibernate, and people stepping through the object tree without realising the amount of database hits it was incurring. Using a DTO helps control this to a certain extent.
- It de-couples our Model from any interfaces. The interfaces become effectivly dumb, and just display data.

One thing that has been raised though, is presenation logic. Should it be included in a DTO. We have JavaScript widgets as well as .Net ones in our app, and not including such logic, means writing the same presentation logic twice.
Left by Rob on Nov 05, 2008 6:47 AM

Your comment:
 (will show your gravatar)


Copyright © Mike Nichols | Powered by: GeeksWithBlogs.net