http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Ayende, I think where you are falling into trouble here with your peanut gallery is that your advice is too general. Martin Fowler says the same thing in P of EAA. Quite simply, if all you are doing is always sending DTOs, then your end-point for the DTO is a Browser that is fully responsible for knowing how to handle its display formats. You give it a MIME type and it is fully responsible for knowing how to render it. That is bad design, because it decouples data from behavior and pushes you back into the structured procedural programming paradigm. You want to hide (in fact run away from) such decisions as fast as possible, and talk strictly in terms of the problem domain. By contrast, have a look at wire protocols like Argot, where more than just a DTO is possible. Also, I agree with you that validation *can be* just data. It is in my applications. I ship "smart clients" that understand a data-driven validation DSL. This is REST. Also, @Eric "Business Logic" is not some coding requirement that requires you to write moon code. For this reason, it is often not that different looking from other forms of code. However, if you want to get a firm understanding of business logic, I recommend looking at academic papers published by "The Process Four (P4)" who explain workflow languages in great detail. Once you understand the higher level details, the implementation is simply coding. http://ayende.com/4011/the-stripper-pattern#comment27http://ayende.com/4011/the-stripper-pattern#comment27Sat, 16 May 2009 22:20:40 GMTEric, There is good reason for that, sample applications, by nature, are made to be simple. Try reading some of the DDD samples http://ayende.com/4011/the-stripper-pattern#comment26http://ayende.com/4011/the-stripper-pattern#comment26Sat, 16 May 2009 04:09:01 GMTIt would sure be nice to see a "what is business or domain logic" presentation with a bunch of practical examples and code. Just about every sample application that I have downloaded, is completely anemic when it comes to demonstrating actual business logic. There is a bunch of data validation and data relationship (customer has orders) logic, but little or no what I would consider domain or business logic. http://ayende.com/4011/the-stripper-pattern#comment25http://ayende.com/4011/the-stripper-pattern#comment25Fri, 15 May 2009 18:14:07 GMT"As I said, you're chopping the privates off the stripper and sending them special delivery." +1 Chase, LOL exactly. http://ayende.com/4011/the-stripper-pattern#comment24http://ayende.com/4011/the-stripper-pattern#comment24Fri, 15 May 2009 17:43:01 GMTSeriously, I lol'd. =) You guys are getting too serious about a blog post that talks about handling privates. http://ayende.com/4011/the-stripper-pattern#comment23http://ayende.com/4011/the-stripper-pattern#comment23Fri, 15 May 2009 16:39:22 GMTCassio, You have a simple property on the DTO, and calculated on on the object http://ayende.com/4011/the-stripper-pattern#comment22http://ayende.com/4011/the-stripper-pattern#comment22Fri, 15 May 2009 15:56:31 GMTHendry, No, ORMs don't send an object over the wire. http://ayende.com/4011/the-stripper-pattern#comment21http://ayende.com/4011/the-stripper-pattern#comment21Fri, 15 May 2009 15:56:01 GMTChase, Try doing a search on the problems of exposing your objects across a system boundary. There is a lot of material out there about that. And sending a class indicator to a different system isn't really useful. You are losing the object context, you have totally different requirements in different sections (UI code doesn't care about business code, frex). http://ayende.com/4011/the-stripper-pattern#comment20http://ayende.com/4011/the-stripper-pattern#comment20Fri, 15 May 2009 15:46:56 GMTThanks for the quick reply. I'm not sure I'm convinced though. I'm willing to abandon the correspondence to physical objects... while it is supposed to be the main benefit of object thinking it doesn't always work out. "Serializing a DTO is about data, serializing an object means that you have to carry behavior as well." Most of the serialization systems I've seen work by serializing only the data and some indication of what the class is. So serialization would seem to be an automated way to do what you are describing as long as the source and target objects are of the same class. "encapsulation problems" At least serialization encapsulates digging into the privates into a standard system library. With DTO's you are explicitly pulling those private data out and sticking them into a special object via "raw" accessor functions. As I said, you're chopping the privates off the stripper and sending them special delivery. I don't see how that avoids encapsulation problems. "versioning" DTO's don't really eliminate version problems. They just push the problem back a level. Neither does serialization, but at least some of the serialization frameworks offer standard way to manage class versions. "different architecture problems" - I have agreed that serializing outside the boundaries of a given architecture makes no sense. I'm not sure how you would even go about trying. "And DTO isn't a mirror image of an object." An example might help. Or perhaps we have both said our peace. http://ayende.com/4011/the-stripper-pattern#comment19http://ayende.com/4011/the-stripper-pattern#comment19Fri, 15 May 2009 14:47:27 GMTChase, No, trying to talk about OO in terms of physical objects doesn't make sense. Serializing a DTO is about data, serializing an object means that you have to carry behavior as well. You can't serialize behavior. So now you are stuck with encapsulation problems, versioning problems, different architecture problems, etc. And DTO isn't a mirror image of an object. http://ayende.com/4011/the-stripper-pattern#comment18http://ayende.com/4011/the-stripper-pattern#comment18Fri, 15 May 2009 14:16:11 GMTI can't agree with this. Here's an analogy with physical objects. A computer is an object. Moving the computer to another room is an antipattern because this entails moving all the private internal parts. Also, if you really like the computer, copying it (i.e. building another one just like it) is an antipattern because it involves revealing all the guts. The only safe way to do this is to build a computer moving/copying machine. The strenght of the object model is supposed to be correspondence to the real world, but I don't see that happening. It seems like the practice you recommend is using DTO's. As I understand it DTO's involve extracting just the data and sending them as a "change transaction". I see three problems with this, given your argument. First, the DTO still needs to be serialized. Second, whether you serialize and send an object over the wire or do that to a DTO, you are still serializing an object over the wire. Third, wikipedia says a DTO "does not have any behaviour except for storage and retrieval of its own data" So while you are saying we shouldn't send "exposed privates" it seems like the recommend method involves chopping off only the privates and sending them in a box, only to be stuck onto a different stripper Mr. potato head style. So to avoid serializing an object and sharing its privates we have (a)shared only its privates (b)created an extra class, and (c)serialized objects of the new class. This seems needlessly complex to me. I am only generally familiar with NHibernate so maybe this conversation is just going over my head... feel free to set me straight. Obviously a lot of folks agree with you so you must be onto something here. Francisco's comment made sense to me... this is about boundaries. Trying to send a raw object outside the boundaries of your system doesn't make sense. But isn't that kind of a straw man? I mean is it possible to successfully serialize an object into a different object model? http://ayende.com/4011/the-stripper-pattern#comment17http://ayende.com/4011/the-stripper-pattern#comment17Fri, 15 May 2009 14:06:45 GMTMany people try to send "privates" over the wire because they don't understand the boundaries of their system. They try to pretend that objects have no boundaries and that they can exist both here and there transparently-auto-magically. They should go CORBA :) Ignoring the wire is one of the worst things one can do. Tailor-made messages which adhere to a given formal contract (be it a XSD, WCF annotations) is the way to go in my opinion (as I always try to explain in NHibernate-Hispano list), so I strongly agree with this post. http://ayende.com/4011/the-stripper-pattern#comment16http://ayende.com/4011/the-stripper-pattern#comment16Fri, 15 May 2009 13:04:57 GMTWell... then all ORMs breach OO contracts? http://ayende.com/4011/the-stripper-pattern#comment15http://ayende.com/4011/the-stripper-pattern#comment15Fri, 15 May 2009 03:52:26 GMTI use DTO's and there is a problem that never know how to solve it well. There are some functions that I wanted to exist in both, BusinessObjects and DTO's. It could be a simple function like: public int GetTotal() { //return sum of 3 private int's } If I put it in my BO I don't have it in my DTO and the reverse is true. I want it in my DTO because I could use it in UI if needed but, of course, I don't want to duplicate it. Where should I put it? I usually end putting it in some Util class, which is a bad thing just like Ayende posted some days ago. What do you do? http://ayende.com/4011/the-stripper-pattern#comment14http://ayende.com/4011/the-stripper-pattern#comment14Fri, 15 May 2009 03:35:02 GMTValidation is something that is usually done at two stages: * UI validation - typically stuff like required, length, range, format, etc * Business rules validation The first is not behavioral aspect of the entity, and that is usually easy to handle by sending the validation constraints with the data when sending on the wire http://ayende.com/4011/the-stripper-pattern#comment13http://ayende.com/4011/the-stripper-pattern#comment13Thu, 14 May 2009 21:58:31 GMTHow is validation not behavior? You have to actually run something to do the validation don't you? Or are you suggesting that the results of validation is what should go along with the data? It seems perfectly valid to want to perform validation in multiple (or all) tiers. Which would be behavior in that case I think. http://ayende.com/4011/the-stripper-pattern#comment12http://ayende.com/4011/the-stripper-pattern#comment12Thu, 14 May 2009 21:49:37 GMTJustin, Validation isn't behavior. If you want to have the same validation, package that up and send it along with the object data. What run on the server and what run on the client are two totally different things. http://ayende.com/4011/the-stripper-pattern#comment11http://ayende.com/4011/the-stripper-pattern#comment11Thu, 14 May 2009 21:45:27 GMTnote to self: research strippers before writing stripper pattern http://ayende.com/4011/the-stripper-pattern#comment10http://ayende.com/4011/the-stripper-pattern#comment10Thu, 14 May 2009 17:13:54 GMTDon't you want a lot of the same behaviors on both sides of the wire? Clearly you want some behaviors only to exist in one place (such as persistence) but what is the best way to reuse validation rules and access rules etc.? If you have objects on both sides with mostly the same behaviors and they are sending / receiving the same data? Are you saying that what travels over the wire shouldn't be the actual object but it is actually ok for the object to exist on both sides? http://ayende.com/4011/the-stripper-pattern#comment9http://ayende.com/4011/the-stripper-pattern#comment9Thu, 14 May 2009 14:42:03 GMTMaybe ... http://ayende.com/4011/the-stripper-pattern#comment8http://ayende.com/4011/the-stripper-pattern#comment8Thu, 14 May 2009 14:26:37 GMTA formal one? http://ayende.com/4011/the-stripper-pattern#comment7http://ayende.com/4011/the-stripper-pattern#comment7Thu, 14 May 2009 14:24:39 GMTnote to self: write up a description of the stripper pattern http://ayende.com/4011/the-stripper-pattern#comment6http://ayende.com/4011/the-stripper-pattern#comment6Thu, 14 May 2009 14:19:42 GMTI love the newly coined anti-pattern. I think it should go well with a re-coined anti-pattern that I developed: YAGNIB (you ain't gonna need it... BEEYATCH). http://ayende.com/4011/the-stripper-pattern#comment5http://ayende.com/4011/the-stripper-pattern#comment5Thu, 14 May 2009 14:15:39 GMTI couldn't agree with you more, and your statement about the stripper was both entertaining and accurate. It does raise the question though, what kind of websites do you frequent in your spare time to come across an image like that? :-) http://ayende.com/4011/the-stripper-pattern#comment4http://ayende.com/4011/the-stripper-pattern#comment4Thu, 14 May 2009 13:28:33 GMTI'm glad to see people talking about this issue more. It's been bugging me for some time now. I think we need some better libraries/languages to reduce the programmer overhead however. http://ayende.com/4011/the-stripper-pattern#comment3http://ayende.com/4011/the-stripper-pattern#comment3Thu, 14 May 2009 12:13:55 GMTWell, thanks a lot for the image. Now I _need_ to get a suit like that for next carnival! http://ayende.com/4011/the-stripper-pattern#comment2http://ayende.com/4011/the-stripper-pattern#comment2Thu, 14 May 2009 12:07:08 GMTAs someone who has had to do some remoting work on current project i agree 100% with this. Send only the data, make the 'object' you send specific to the remoting request and keep it simple. http://ayende.com/4011/the-stripper-pattern#comment1http://ayende.com/4011/the-stripper-pattern#comment1Thu, 14 May 2009 11:06:13 GMT