Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Component Design Considerations
How do you know which logic goes in which tier? There is no absolute rule, but a good rule of thumb is the following: If it's a piece of logic that might be executed no matter what type of UI (Web or Windows), it probably should be coded in the middle tier.
When developing database maintenance applications such as these, I find that a good design is to expose two types of objects, or classes, from the DHO for each table involved. One class encapsulates the table itself. In order not to confuse this class with the actual database table or with a VB collection, I call these "list" classes. The other class to expose from the DHO is one that encapsulates a single entity (that is, row or record) from the table. In my sample application, the clsPublishersList class encapsulates the entire Publishers table, and the clsPublisher class encapsulates an individual Publisher entity from the Publishers table. These two classes will work closely together to provide the necessary functionality that allows the applications that use this component to search the Publishers table; and to fetch, insert, update, and delete the data for an individual Publisher.