On Performance: I agree with Imar. Only the data of a class is serialized (and at that, only the PUBLIC data). So I don't think there is a significant performance difference between a "smart" and "dumb" class.
Regarding organization of classes: I feel that classes that provide data transport as well as processing logic (i.e. 'Smart' classes), break the purist design of multi-layer architecture.
Let's consider the application (app), business logic layer (BLL), data access layer (DAL), and business objects (BO) for the "smart" class approach. Here are a few givens:
1. BO classes defined in BLL
2. app needs to talk to BLL
3. BLL needs to talk to DAL
In this scenario, you can't consume the BO classes in the DAL because you'd get circular references. Therefore, your DAL logic has to work completely independent of BO knowledge. Thus, you have to have BLL methods that create objects from data structures. I see this as a conflict to business/data logic separation. The business logic layer contains data logic.
Having a standalone business object (BO) library allows you to consume it by the business layer (to work with the objects) and the data layer to persist and retrieve the objects.
It also provides these advantages:
- Portability: you can reuse the data shells without carrying around any logic that may not apply to the application you're reusing them in. (Although, typically you would not reuse a set of classes without some similar business logic, they would usually go hand-in-hand).
- SOA: I could create a thin-client application that will do the majority of it's work through a web service. I can include the BO library in my application without any logic behind it. My web services could accept and return XML containing serializations of the BO classes. An important distinction to note here: when you make a native .Net web reference, a proxy class is created that defines class stubs that represent the classes exposed by the web service. While the public interface to these classes appears similar they are not the same class types as the business objects on the service side.
So you have to write the services a little different. One way is to have them accept and return strings of XML (versus a strongly typed object). You need to de/serialize the objects on either end yourself. I realize this increases the complication of code and negates the automatic plumbing that .Net does for you, but in the end results in a more consistent application structure because you are truly using the same class types on both ends of the service.
To provide further flexibility to the design:
If you have a completely self contained data access layer you can implement interfaces on its classes. Then you program the business layer against those interfaces instead of against concrete class types such that you can swap out the data access classes, or even the entire library itself. This could permit you to switch (using a simple configuration switch) what type of data source you want to use: RDBMS, XML, remote service (web/remoting), etc.
-
Peter
