Last post Jun 10, 2013 03:54 PM by Illeris
Jun 10, 2013 12:12 PM|ramana123|LINK
got a question like is it good architecture to have System.Data namespace usage in UI layer? I mean usage of Data Sets/Tables iin UI layer which returned by BUS logic.
Wanted to see in 3 tier architecture is it okay to use said above or passs objects between layers?( if so what is benefit)
Jun 10, 2013 03:48 PM|agillanders|LINK
To a degree this is a matter of personal/company style but my vote is a strong no - it is not good practice. The business layer and data layer should be shielding the UI developer from knowledge of persistence structures and their are plenty of strongly
type generic collections you can provide to the UI layer if you really need that, or simply implement your own collection class in the business layer.
My only compromise is the use of SqlDataSources for READ ONLY access to data and only when a business layer object cannot provide the necessary data. The productivity of custom list/grid creation is so enhanced by this that I do find it justified. But any
write access from pages must be via business layer objects regardless. I don't allow the default write/insert functionality in the presentation layer. Although initially this can seem productive it is just asking for trouble as folks, usually unintentionally,
bypass all the careful validation / cascade events built into the business layer.
Just an opinion of course.
Jun 10, 2013 03:54 PM|Illeris|LINK
Use objects, not datasets. These create large overhead, consume much more memory, and if not disposed correctly, they cause issues with garbase collection (sensitivity in web apps). For winforms or WPF : not recommended, but less relevant. However, it's
not a good practice to use them with WCF services.
In brief : if you are building a commercial web app or a web app that will have a lot of users, datasets are not recommended. For quick (& dirty) apps => who cares :-)