http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660David, If your app requires this, it is an excellent approach, certainly! http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment20http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment20Sun, 29 Aug 2010 15:19:43 GMTAyende - totally agree with the concept here. I use Agatha to support this type of architecture. One difference is the way I do queries (read-only requests). Instead of loading domain model entities and building DTOs from them, I just maintain a view in the db and have a specific readonly model that I query against (using NH of course). This makes the queries super simple, at the cost of having to maintain two sets of mappings. Thoughts? http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment19http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment19Sun, 29 Aug 2010 14:45:12 GMTThe CSLA framework does not restrict from the design you seem to prefer. I frequently use CSLA with DTOs. CSLA objects are my equivalent of the View Model containing the authorisation, validation rules and change notification. The CSLA and DTO objects contain only the information they need to complete the scenario for which they are designed. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment18http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment18Mon, 09 Aug 2010 16:22:35 GMTThe hardest part is coming up with expressive and accurate names for your DTOs without using stupid suffixes like '2' and 'Data'. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment17http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment17Mon, 09 Aug 2010 07:42:40 GMTUsing DTOs is, and always has been a good idea for expressing information between persistence and UI. Sure there are technologies that pop up that say it's no longer necessary, but the fact is that DTOs are simple, easy to maintain, and suited to their single purpose. Sure, you'll get technical staff that grumble at the thought of having two or three different DTO classes to express "mostly" the same information. But I'd rather deal with them grumbling about spending a few extra minutes customizing a DTO than telling customers they can't do something a bit different on one screen because the data isn't arranged that way, or adding complexity to suit a specific change, or risking introducing an ugly bug. (Plus dealing with the performance cost of sending more data than I need to for the sake of consistency.) It's like a tug of war between DNRY and SRP, IMO SRP should always win. A DTO should be responsible for servicing it's view, and only it's view. If it can service 2 views without any conditional changes or complexity, great. But as soon as that changes, the DTO gets subclassed. Tidy. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment16http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment16Sat, 07 Aug 2010 06:28:26 GMTGreat, I can't wait to read it. Although it seems I will have to be patient, two weeks of post waiting already. :D http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment15http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment15Fri, 06 Aug 2010 16:35:36 GMTAlberto, I'll discuss that in a future post http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment14http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment14Fri, 06 Aug 2010 15:49:20 GMTWriting a specific DTO class is the easiest part. Copying the data between objects requires AutoMapper or a similar tool that uses reflection which might be not acceptable with some clients. Doing mappings by hand would require a lot of stupid code. You would also have to duplicate numerous data validation rules and attributes so you can validate object data at the UI level. I agree that from the application maintenance point of view, separate models make it easier. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment13http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment13Fri, 06 Aug 2010 15:24:15 GMTWhat would be the problem with ActiveRecord? I don't get it. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment12http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment12Fri, 06 Aug 2010 15:20:05 GMTI went through the same thoughts 1,5 years ago. I was using MVC with the ViewData dictionary but once I found out that it literally takes a minute to write the view model class I never looked back. It just doesn't cost that much to do it right. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment11http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment11Fri, 06 Aug 2010 13:44:35 GMTStuart, In fact, that is the main point, you usually _don't_ need to do so. For that reason I advocate working on separate view models for each screen, and dto per scenario. Considering the way we usually work, the work is already done per screen, so adding a new prop is a no op, essentially. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment10http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment10Fri, 06 Aug 2010 11:54:00 GMTDepending on the use cases you may not need to modify all the screens ;-) http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment9http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment9Fri, 06 Aug 2010 11:52:52 GMTThomas, And? For mapping between entities & dtos, you can use a tool like AutoMapper. But more to the point, so you got 6 properties to write. Time to do that? 3 minutes? Remember that you have to also modify all three screens, which is going to take a _lot_ longer, so this is not even noise. What you gain is drastically simpler architecture and easier to work with system. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment8http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment8Fri, 06 Aug 2010 11:45:17 GMTOkay, that makes sense, but you still have a lot of duplication on the property level, don't you? Imagine you want to add a new property to the machine entity (e.g. manufacturer name). You may have 3 screens that need to display this new property. So to add only 1 property you have to add the poperty to the machine entity, to the database, 3 DTO classes and possibly another 3 view models. And you need some kind of mapping between Entity, DTO and View Model, so the property data is transferred properly between the layers. Only looking at the database and entities it's probably handled by an ORM, but what do you use to fill DTOs and View Models? http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment7http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment7Fri, 06 Aug 2010 11:41:26 GMTTom, I wouldn't, I find ActiveRecord too limiting in real world scenarios. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment6http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment6Fri, 06 Aug 2010 11:14:48 GMTWhat do you suggset when your forced to use an ActiveRecord DAL, you have to bring back everthing which is a pain. Would love to use something like nhibernate ORM or SubSonic, but DBA and team leader very much against it.... :( http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment5http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment5Fri, 06 Aug 2010 11:11:43 GMTSounds also like the client is trying to use one CSLA class per db entity .. the intention with CSLA afaik is to use one (or more) CSLA class(es) per use case.. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment4http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment4Fri, 06 Aug 2010 11:05:03 GMTYes, I fully agree with you arguments. Just wanted to confirm my understanding. Thank you very much for this post. It is enlightening. http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment3http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment3Fri, 06 Aug 2010 10:39:56 GMTPetar, DTOs are stupid classes that you can write in a heartbeat. Simple, single use, API is easy to work with. Yes, you end up with a large body of simple, easy to understand, easy to work with code. That is a GOOD thing http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment2http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment2Fri, 06 Aug 2010 10:20:46 GMTYou end up with many DTOs, then ? If you display Machines on 3 slightly different pages would you end up with 3 MachineDTOs ? Would you than end up with 3 different APIs to retrieve this 3 MachineDTOs ? Is so, you are than creating your API to serve specific view requirements, iow your API is not generic ? Or you would have one API set for UI layer and another for unknow 3rd party application clients for integration ? http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment1http://ayende.com/4576/data-access-is-contextual-a-generic-approach-will-fail#comment1Fri, 06 Aug 2010 10:14:22 GMT