In a 3-Layer application, from better design/architecture point of view, can/should i instantiate a business class (which resides in Business Layer) in Presentation Layer? I mean, is that a bad practice? If so, then what are ways to refer to any business object from the Presentation Layer?For example, how i'm gonna save an "Employee" object in session state if i can't create it in the Presentation Layer(code-behind)?
A:
If you don't instantiate the business object in the presentation layer, how would you call it? So you shall have to do it. Of course, if you wish the code for business layer to run off somewhere else, you can think of services. But still, at that time you shall instantiate the proxy from the business/service layer only. So just go ahead.
Kangkan
2010-09-25 05:09:38
ya, infact i always do that, but i see some previous argument on this topic, here in stackoverflow. some r saying it makes the design tightly coupled, and about using an interface exposed by the business layer or using DTOs, etc. so as an amature/novice programmer i'm a bit confused if i'm doing wrong or right (again, from better design point of view).
Nero
2010-09-25 05:45:59
What you are saying is right. If you wish to keep it very loosly coupled, never ever instantiate a class directly. Rather always use an interface and possibly a factory method configurable enough to actually instantiating your classes. The data to be sent from one layer should always be using DTO and you can actually derive your DTO from an interface. That will make your life easy if you need to change the DTO in the future.
Kangkan
2010-09-25 06:07:24