ProjectTracker style DTOs vs MobileObject derived DTOs #3528
-
Gentlemen, this is related to #3527 . Regards |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Mostly it depends on whether you plan for the DTOs to flow through the data portal or not. In things like ProjectTracker, the DTOs exist purely within the data access layer, so they never flow through the data portal. As a result, they don't need to be mobile objects. They exist (briefly) within one physical tier, assuming the app is deployed in an n-tier model. I suppose there could be reasons why you'd flow a DTO over a layer/tier boundary, though that's not really the intent of a CSLA architecture. Maybe (maybe?) you'd flow a DTO to a client instead of using a readonly domain object because you know there are not any authorization rules associated with the data involved? Personally though, I think I'd still use a readonly type because you never know when the users will come back and start adding business requirements like authz rules. |
Beta Was this translation helpful? Give feedback.
Mostly it depends on whether you plan for the DTOs to flow through the data portal or not.
In things like ProjectTracker, the DTOs exist purely within the data access layer, so they never flow through the data portal. As a result, they don't need to be mobile objects. They exist (briefly) within one physical tier, assuming the app is deployed in an n-tier model.
I suppose there could be reasons why you'd flow a DTO over a layer/tier boundary, though that's not really the intent of a CSLA architecture. Maybe (maybe?) you'd flow a DTO to a client instead of using a readonly domain object because you know there are not any authorization rules associated with the data involved? Personally tho…