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.