Hi Shawn,
Good questions! OOP is all about thinking first, and coding later.
I see a couple of holes in your understanding of these principles. The first
is understanding which layer knows what about which other layer. Whether
you're talking about a 3-tier or more-tier app, the principle is failry
simple: Each tier is a client of the tier below it. That means that no tier
knows anthing about the tier above it, and only knows about the tier
immediately below it. Example:
Presentation Tier
Knows about Business Tier (1 below)
Does NOT know about Data Tier (2 below)
Business Tier
Knows about Data Tier (1 below)
Does NOT know about Presentation Tier (above)
Data Tier
Does NOT know about Presentation Tier (above)
Does NOT know about Business Tier (above)
How does the Business tier communicate with the Presentation tier? It used
Properties which the Presentation Tier can read, and Events which the
Presentation Tier can subscribe to.
What this means with regards to Question number 1 ("How do I obtain a
Customer business object pre-loaded with data from the database"), the
answer should be obvious after understanding this principle. The Customer
class is a business class. It may know about the Data Layer. So, yes, you
could create a Contructor that takes a Customer ID and populates the
instance from the Data Tier. Or you could create a Customer ID property in
the Customer class that, in the setter method, fetches the data from the
Data Tier, and populates the instance with it. The second is the better
method. The first method can also be used, by overloading the Constructor,
and in the variation that takes a Customer ID, use the setter method of the
Customer ID property to populate the class. Very Simple Example:
public class Customer
{
private string _ConnectionStri ng = "Your Default Connection String";
public string ConnectionStrin g
{
get { return _ConnectionStri ng; }
set { _ConnectionStri ng = value; }
}
private string _FirstName;
public string FirstName
{
get { return _FirstName; }
set { _FirstName = value; }
}
private int _CustomerID;
public int CustomerID
{
get { return _CustomerID; }
set
{
// Set the private member
_CustomerID = value;
// (Imaginary Data Tier method)
// Note that the Data Tier only knows what it is told
// about the data it's working with.
// The business tier knows how to use the Data Tier.
DataTable dt = DataTier.GetDat aTable(
"TblCustome r", "CustomerID = " + _CustomerID,
_ConnectionStri ng);
// Populate the instance
_FirstName = (int)dt.Rows[0]["FirstName"];
}
}
public Customer() {}
public Customer(string connectionStrin g)
{
_ConnectionStri ng = value;
}
public Customer(string connectionStrin g, int customerID)
{
// Changes the Default Connection String
_ConnectionStri ng = connectionStrin g;
// Note the use of the setter method here
CustomerID = customerID;
}
public Customer(int customerID)
{
// Note the use of the setter method here.
// This overload uses the Default Connection String
CustomerID = customerID;
}
}
The second thing you seem to be missing is that a class and an object are
not the same thing. There is only one copy of a class. There can be many
copies of objects. An object is an instance (or copy) of a class.
So, when you ask
"How do I obtain a collection or ArrayList of Customer objects in the case
where I need to return more than one customer object?"
and you say
"The other option is to put a method in the Customer business object to
return an ArrayList of Customer business objects"
it seems that you're mixing up classes and objects. The solution is to
create a Collection class that can be used to store multiple Customer
instances. The best thing, rather than using an ArrayList, is to create a
strongly-typed Collection that always works with Customer instances.
Question 3 is answered in my opening remarks about what layer knows what
about the other layers.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.
"iTISTIC" <sh***@itistic. com> wrote in message
news:11******** **************@ v46g2000cwv.goo glegroups.com.. .
Developing a new app and am trying to make this my first truly
OOP/3-Tier app. I understand the principles of the presentation,
business, and data layers. I do, however, have some questions on where
certain functionality should be placed and how some things should be
implemented.
Let's use a simple example such as an application to manage customer
records (customer_id, first_name, last_name). I'd have a Customer
business object with ID, FirstName, and LastName properties. What I
don't understand is the following:
1. How do I obtain a Customer business object pre-loaded with data from
the database (customer_id 3 for example). I could create a constructor
in the Customer business class with the customer_id as a parameter and
have the constructor call the data layer to return a dataset containing
the customer's data and then set the properties accordingly. Is this
how this is normally accomplished? I could also have a method in the
Customer data layer that accepts a customer_id as a parameter and
returns a Customer business object. My only problem with this is that I
have it in my head that the presentation layer should never communicate
with the data layer. Some help here would be great.
2. How do I obtain a collection or ArrayList of Customer objects in the
case where I need to return more than one customer object? Such an
example would be a form that listed all customers. Calling a method in
the Customer data layer to return an ArrayList of Customer business
objects would work here as well, but this is breaking the same rule of
having the presentation layer working with the data layer. The other
option is to put a method in the Customer business object to return an
ArrayList of Customer business objects, but then my code has to
instantiate the Customer object simply to return more Customer objects.
This is unless I make the method in the Customer business object
shared.
3. Data layer methods to insert, update, delete database records -
Should the insert and update methods accept business objects as
parameters or should they accept a long parameter list that contains a
seperate parameter for each of the business object's properties?
Any help anyone can provide here is more than welcome. These issues
have been keeping me from developing an OOP/3-tier solution for quite
some time as I just can't seem to force myself to develop a system
without truly knowing how these issues should be tackled the proper
way.
Thanks in advance for your help!
Shawn Berg
