OK, the title is buzzwordy and doesn't mean much but here is the question I want to pose as we evaluate the relative priorities of various multi-tier scenarios in DLinq.

Do you use the same type on mid-tier and on presentation / web-service client tier?

I have seen many discussions about how some people want to use the same assemblies on mid-tier and presentation tier (or even on web-service clients). I personally think that the two should be designed separately and should not be the same unless there is a justification for it. What you retrieve from database and use on your trusted mid-tier may be quite different from what you expose to a large number of clients - whether presentation tier of your app or consumers of your web-service sitting in another organization.

However, there are others who passionately argue that it is the same data everywhere and so the ability to use the same objects on multiple tiers is critical. DataSet and typed DataSet users in particular often champion this cause and love the fact they have a single package that captures data retrieved from DB, data sent over the wire, data bound to forms, data returned to the mid tier and data persisted to the DB. Some even go beyond data and claim that the minimal attached behavior is also common - e.g. validations.

My question is - do you have good scenarios where having the same objects really makes sense? Or are these more corner cases? Have the SOA priests just missed the practicality of such scenarios or are they right about bashing tight coupling?