http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Some people just don't understand the difference between layers and tiers. Using a layered architecture is generally good, but that doesn't mean you need to run them on separate tiers (and in fact, it causes problems with performance and more). I've seen this problem before; I hope you sorted them out. http://ayende.com/4071/don-t-castrate-your-architecture#comment25http://ayende.com/4071/don-t-castrate-your-architecture#comment25Tue, 11 Aug 2009 13:42:11 GMTNiraj, Actually, I don't mind overly much if you do the controller stuff directly in the WCF service, no. http://ayende.com/4071/don-t-castrate-your-architecture#comment24http://ayende.com/4071/don-t-castrate-your-architecture#comment24Thu, 23 Jul 2009 18:24:04 GMTAyende, Normally we have the practice of clubbing WCF layer and Controllers (the usecase coordinator). We infact had no controller layer and WCF use to coordinate between the entities + transactions. Again I could have separated them but it was sort of creating a one to one mapping in both places. Do you have a something like stripper pattern (evaluating pros / cons) for this? We weren't creating a SOA style app. http://ayende.com/4071/don-t-castrate-your-architecture#comment23http://ayende.com/4071/don-t-castrate-your-architecture#comment23Thu, 23 Jul 2009 12:01:54 GMTI think its better to have some demos of N-Tier best practices of "WCF and NHibernate" rather than talking in air. http://ayende.com/4071/don-t-castrate-your-architecture#comment22http://ayende.com/4071/don-t-castrate-your-architecture#comment22Wed, 22 Jul 2009 10:42:55 GMTAyende, I would love to see more of your findings on WCF and NHibernate usage. I recently started to use WCF and have been using nhibernate already for a fair amount of time. There seem to be several hoops which the combination of the two technologies make you jump through, like where to put the session factory etc. Would you do a few demo apps or more blog posts for how you would recommend the two technologies working together? and where the common pitfalls are. I think this would make the NHibernate and WCF combination clearer to people, it would also help my understanding out immensely. Thanks Pete http://ayende.com/4071/don-t-castrate-your-architecture#comment21http://ayende.com/4071/don-t-castrate-your-architecture#comment21Tue, 21 Jul 2009 14:53:51 GMTNiraj, Please note that I advocate this type of architecture for a multi tier applications only. If it is just running on the same machine, things are different, but for multi tiers, yes, you ARE going to have to do something about it. http://ayende.com/4071/don-t-castrate-your-architecture#comment20http://ayende.com/4071/don-t-castrate-your-architecture#comment20Tue, 21 Jul 2009 14:38:15 GMT@Ayende, I get the point though WCF serializes only public part by default. But this is becoming crazy. I have entities layer, then I have DTO, and then if I am using something like MVVM like will have one more ViewModel. Lot of duplication :(. Anyways I will take it up in my next project with UI validation implemented inside ViewModel properties. One more query in your post of UI should talk to DAL, you have a query wrapping business logic & then high level components paginate it. But do you mean that I have to retrive all data in my App layer & throw a window of it to presentation? @lexx, I had used stateless singleton WCF implementation & it worked well for me. And all the logic related to given data was consolidated in a single place & assembly was shared (no add service reference - just IChannelFactory interface) http://ayende.com/4071/don-t-castrate-your-architecture#comment19http://ayende.com/4071/don-t-castrate-your-architecture#comment19Tue, 21 Jul 2009 14:28:38 GMTPeter, See my post about the DAL why I don't really like the division into BL and DAL. I consider it false way of doing thing. I would much rather have a single layer which handle BL and infrastructure bits around it. http://ayende.com/4071/don-t-castrate-your-architecture#comment18http://ayende.com/4071/don-t-castrate-your-architecture#comment18Tue, 21 Jul 2009 13:42:19 GMTcowgaR, Not really, a single request tend to do one thing, so you usually pack it into a DTO and send it to the backend, where it unpacks itself and do something meaningful. The best description of that is from Udi: [www.udidahan.com/.../entity-framework-disconnec...](http://www.udidahan.com/2007/03/30/entity-framework-disconnected-problems-solutions/) If you want to use NH builtin support for that, take a look at session.Merge http://ayende.com/4071/don-t-castrate-your-architecture#comment17http://ayende.com/4071/don-t-castrate-your-architecture#comment17Tue, 21 Jul 2009 13:41:08 GMT@Ayende. The app layer *is* the business layer. Talks DTOs externally, and then either manipulates business domain classes directly or via services. By "business layer" I mean "application API" - not sure if we are using the same terminology or not. http://ayende.com/4071/don-t-castrate-your-architecture#comment16http://ayende.com/4071/don-t-castrate-your-architecture#comment16Tue, 21 Jul 2009 13:37:50 GMT@lexx You might like AutoMapper. http://ayende.com/4071/don-t-castrate-your-architecture#comment15http://ayende.com/4071/don-t-castrate-your-architecture#comment15Tue, 21 Jul 2009 13:34:56 GMTIf anything is going to castrate your architecture, it is running your business of a Windows Home Sever. :) http://ayende.com/4071/don-t-castrate-your-architecture#comment14http://ayende.com/4071/don-t-castrate-your-architecture#comment14Tue, 21 Jul 2009 13:24:09 GMTthat's why I put entity in parenthesis... but as far as I know it doesn't matter if it is DTO or entity, I still need to track changes down... so, using NHibernate, and DTO, what is the recomended approach in asp.net mvc layer to communicate with application layer if detatched entities are not recommended solution? thanks for answer http://ayende.com/4071/don-t-castrate-your-architecture#comment13http://ayende.com/4071/don-t-castrate-your-architecture#comment13Tue, 21 Jul 2009 13:12:15 GMT@lexx, Yes, I want them to be separate classes. Moreover, I want different classes for different scenarios. CustomerForOrder is different than CustomerForLogin If you care about the code to convert it, use AutoMapper, but it is really not much of a problem. @Arild, You don't push entities on the wires, and you don't do anything with them in the UI layer anyway, so there is no problem. @Mike, That really depend on too many variables to answer, but ideally, yes. The web server would be mostly HTML generation and request handling, mostly out of local cache. The app server would handle request that require data or BL, and send them to the local cache of the web server. http://ayende.com/4071/don-t-castrate-your-architecture#comment12http://ayende.com/4071/don-t-castrate-your-architecture#comment12Tue, 21 Jul 2009 13:01:11 GMTcowgaR, NH does have support for detached entities, it is just not a recommended approach. As for the image, I agree it is ridiculous. I wouldn't pass entities around, the UI deals with DTOs, never entities. Also, note that we are talking about tiers vs. layers, that is an important distinction http://ayende.com/4071/don-t-castrate-your-architecture#comment11http://ayende.com/4071/don-t-castrate-your-architecture#comment11Tue, 21 Jul 2009 12:58:22 GMTNiraj, No! Yuck, you don't want to share entities on the wire, see the stripper pattern post about why. http://ayende.com/4071/don-t-castrate-your-architecture#comment10http://ayende.com/4071/don-t-castrate-your-architecture#comment10Tue, 21 Jul 2009 12:56:04 GMTPeter, In general, I agree about the DTO, but I am not sure that I agree with hiding the BL in any way. The app tier tend to talk in DTOs externally, and entities internally. http://ayende.com/4071/don-t-castrate-your-architecture#comment9http://ayende.com/4071/don-t-castrate-your-architecture#comment9Tue, 21 Jul 2009 12:54:52 GMTJust to clarify, you'd use WCF to expose an API from the Application Server to the Web Server and keep the web server solely for handling requests? Thanks, Mike http://ayende.com/4071/don-t-castrate-your-architecture#comment8http://ayende.com/4071/don-t-castrate-your-architecture#comment8Tue, 21 Jul 2009 12:24:27 GMT@ Peter, In case we have separate classes we will have to copy data transferred from DataContract to entity in order to manipulate entities in the App Server. This sounds like a duplicate code. Don't you agree? @ Niraj, Mostly agree. Are you using session per request on the App Server side? Have you tried this kind of architecture on the high loaded apps? http://ayende.com/4071/don-t-castrate-your-architecture#comment7http://ayende.com/4071/don-t-castrate-your-architecture#comment7Tue, 21 Jul 2009 12:10:58 GMT__“that is how we do things” is number 4 practice of the guide "how to beat a dead horse" :) but the guy may have its own truth, because once you start building SOA applications, you DO need some kind of seperation, although the picture portraied is really ridiculous. I think it is harder to do with NHibernate (although it is an awesome framework, congratz to 2.1!) but there are some, like LLBLGen, which offers change tracking inside entities, thus serializing them and transfering on wire isn't such a serious problem. And lazy loading is a dangerous thing this way or that way :) Btw, I don't see solution either in your picture, how would you transfer "entity" from the UI layer back to your Application Server layer if not using services? How would you track changes? Just asking, we both know who's guru here :) Care to elaborate more? btw EXCELLENT post, I would really welcome more on this topic! http://ayende.com/4071/don-t-castrate-your-architecture#comment6http://ayende.com/4071/don-t-castrate-your-architecture#comment6Tue, 21 Jul 2009 12:10:16 GMT@lexx, generally it's not required. Infact DTO's created would club many entities together. Some people seperated DTO from entities because of .NET attributes imposed by WCF but that also I guess is no longer mandatory with .NET 3.5 SP1. Infact I would suggest you to share the entire Entity layer assembly with your presentation which would help you consolidate your validation logic as well (unless you are in a SOA mode). @Arlid, I agree with you. Normally a single server should suffice (and is best in terms of performance, etc.) unless your Security requirements mandate it. http://ayende.com/4071/don-t-castrate-your-architecture#comment5http://ayende.com/4071/don-t-castrate-your-architecture#comment5Tue, 21 Jul 2009 11:21:24 GMTArild: He is meaning lazyload/caching from the App to database. (WCF at the App level, NHibernate used 'behind' the WCF interfaces) http://ayende.com/4071/don-t-castrate-your-architecture#comment4http://ayende.com/4071/don-t-castrate-your-architecture#comment4Tue, 21 Jul 2009 11:15:43 GMTIn the suggested solution, I'm assuming WCF is used for communication between the web server and the app server. Don't you run into some of the same problems with lazy loading and caching there? http://ayende.com/4071/don-t-castrate-your-architecture#comment3http://ayende.com/4071/don-t-castrate-your-architecture#comment3Tue, 21 Jul 2009 09:20:34 GMTDepends on how complex the business layer is really. If it is very complex then you might need to hide the structure of the domain classes behind an app layer; but the important thing is that you talk in application API (data transfer objects) rather than instances of domain classes. The DTOs will not only have all required data loaded but will not have any properties there which aren't required for the specific use case; preventing someone from "just using the one that is already there to do something else" - which would run you into lazy load problems because the object is not connected to a session. http://ayende.com/4071/don-t-castrate-your-architecture#comment2http://ayende.com/4071/don-t-castrate-your-architecture#comment2Tue, 21 Jul 2009 09:09:54 GMTAyende, when we deal with WCF we have Data Contracts for DTO and at the same time we have domain model and entities in our App Server. Lets say we have a customer entity and a customer datacontract. The fields of this classes will mostly be the same. Do you suggest anyway to have them as separate classes? http://ayende.com/4071/don-t-castrate-your-architecture#comment1http://ayende.com/4071/don-t-castrate-your-architecture#comment1Tue, 21 Jul 2009 08:28:01 GMT