[Kosmo]

Hey guys I've been developing in C++ for awhile but I am learning C# and trying to start applying good OOP concepts. I am having a hard time finding good tutorials on the ideas of having User Interface, Command Processor, Business Logic, and Data Access Layer.

Say I have a parent class "Fruit" and a bunch of child classes representing different types of fruit.
I have a List<Fruit> to contain all my fruit.

In the UI class would I simply ask the user what type they want to create, get all the data in a string array then pass it to the CP class? The CP class would do input validation then pass it to the BL which for inserting into a database it would just pass it to the DA class.

Would the DA layer have different methods like, "AddBanana()", "AddApple()", etc? Or one "Add()" method which it would somehow be able to figure out what type it is to instantiate the proper fruit object and put the information in it then add it to the List.

Or would the BL layer instantiate the proper fruit and fill in the information and pass it to the DA class which would just take a Fruit object as a parameter and add it?

I'm quite confused on exactly the flow and role of all of these layers and what each layer is allowed to know about. I imagine its going to get much more confusing when I get into updating, querying and deleting.

Here's a sample code for a DA layer, what am I doing wrong?

public string Lookup(Types type)
{
List<Parents> search = new List<Parent>();


switch (type)
{
case Types.TypeOne:
{
search = ParentDataBase.FindAll( delegate(Child1 findChild) { 
return findChild is ChildOne; } );

}
break;
case Types.TypeTwo:
{
search = ParentDataBase.FindAll( delegate(Parents findChild) { 
return findChild is ChildTwo; } );
}
break;
case Types.TypeThree:
{
search = ParentDataBase.FindAll( delegate(Parent findChild) { 
return findChild is ChildThree; } );
}
break;
}
string results = "";

foreach (Parent x in search)
{
results += t.ToString();
}
return results;

[Skydiver]

From what I've seen, there are a couple of different philosophies when it comes to n-tier architecture and communication between tiers.

Some believe that there are objects that are naturally part of the problem domain, and so those objects are free to be passed around all the way from the UI down to the Data Access and back up again. If the tiers happen to be on separate machines or processes, then the object needs to be serialized.

Others believe that each tier has a natural object that best suited for work in that tier/layer. Since the rule with n-tier architectures is that you can only communicate with the layer above or below you, then you need translate your layer's natural object to an object compatible with the layer you want to talk to.

And yet another point of view is that communications between layers should always be in some easily serializable format like XML, JSON, strings, etc. From what I recall some of the early MS examples of .NET n-tier programs used DataSets to communicate between tiers/layers. Since DataSets can be serialized this worked out nicely.