WebService Usage
Hmm.
Always for the sake of clarity, I believe that some
more words should be spent on in which sense WSs "are another layer in a
multi-layer architecture"... They introduce some kind of factorization of the
enterprise ecosistem, sure: however I'd say that their taxonomy is somewhat
orthogonal to the tier one. They are deeply different in purpose: just think at
all the orchestration patterns that WS leverages as opposed to the rigid roles
that carachterize the PLBLDAL.
I think that the key concept here is that the design
of a business object is supposed to be done exactly like in the past: having WSs
today allow you to gather a functional team of objects(components?) that,
taken together, supply (guess what?) a service. Such objects can be from
both the BL and the DAL, hence the orthogonality.
Regarding the embedding of business logic in the web
service: since the WS supply a different coarseness in the offered functionality
and can have to coordinate the interaction of different lower level objects, I
believe it's perfectly reasonable that such coordination could imply a centain
dose of (business) logic. It's not wasted by any mean: by scale selfsimilarity,
this could be equivalent to say that the orchestration logic among WSs of one
enterprise process is "wasted" as well.
I'm afraid that, more than the articles that for sake
of simplicity fail to supply a canonical concept of service, the problem is that
it's not entirely clear what a service architecture overimposed on a old fashion
one can do for the enterprise: we have the mean before having an exact
idea of what what we can achieve with that mean. Such goals are, very
often, more business related than pure technical stuff: so the typical
situation is that who has the skin in the game can't yet think in term of
services and since he can't think in such term he can't as well see the
(enormous) advantages specific to his business.
Sorry if my bad English messed up the meaning :-)
I saw Julie's post that took me to Alex's post and I really like this
subject. However, I don't totally agree.
I
definitely agree that WebServices are another layer in a multi-layer
architecture. What I don't totally agree with is that there should be no
logic in a WebService. That it should only act as an "interface"
layer. I think in a perfect world, where everybody follows best practices
and has all the time they need to do projects, this would be the way to
go. A lot of companies have to weigh "the best way to do something" vs.
"the fastest and most cost effective way to do something". A lot, I would
guess, decide that if the business logic is small enough and will never be
reused, that it would be better to just throw it in the WebService. The
more OOP-like you make an application, the easier it is to update in the
future. It also goes the other way though, and can make updating more
tedious.
The
last project I worked on (that's not quite done yet actually) had about 1500
lines of code in it. Basically though, all the logic in the WebService is
really just to "shape" the data that comes from my DAL. Should I move all
that shaping code into another Assembly or even just another class?
Maybe. If I don't, am I screwing myself over in the future? Not
really.
I just
think that there's no difference in programming practice between say WebForms,
WebServices & WindowsForms (besides the fact that WebServices don't have
UI). It's a "best practice" to not have any business logic in your UI (or
in your WebService, stated by Alex), but does everyone follow that? Not at
all. Again, I believe the reason being, simply because of time and
weighing the benefits.
That
said, I agree with Alex, that business logic should be outside of your "layer
interface". I don't think, however, that if you don't do it that way, you
should be looked at as someone who doesn't know what they're doing.
Situations vary.