Three/Multi Tier/Layer Architecture/Design by Scott Hanselman

posted Tuesday, June 01, 2004 10:28 AM

Listen to him... Thank you.

6 Comments

# re: Three/Multi Tier/Layer Architecture/Design by Scott Hanselman

Tuesday, June 01, 2004 6:50 AM by Scott Williams    
Question, would this be bad in the Business layer, and if so, what is a better way to do it?

class SomeClass {

private DataRow row;

internal SomeClass(DataRow row)
this.row = row;
}

public string Name {
get { return this.row["name"]; }
}

Generally, this class would be part of a strongly typed collection (hence the internal constructor), so it could guarentee that the DataRow contains a "name" field.

# re: Three/Multi Tier/Layer Architecture/Design by Scott Hanselman

Tuesday, June 01, 2004 7:07 AM by Steve    
Scott, Using that approach you're forcing your business object to know about your data store. Since the data row is a representation of the row in your database you have a coupling between your business object and database which isn't optimal. I would seperate out the responsibility of loading your SomeClass with data from a DataRow into a seperate class, or put it in the Data Access Layer.

# re: Three/Multi Tier/Layer Architecture/Design by Scott Hanselman

Tuesday, June 01, 2004 7:36 AM by Scott Williams    
That's what I figured, I was going off of this article: <a target="_new" href="http://www.microsoft.com/belux/nl/msdn/community/columns/hyatt/ntier2.mspx">http://www.microsoft.com/belux/nl/msdn/community/columns/hyatt/ntier2.mspx</a>



# re: Three/Multi Tier/Layer Architecture/Design by Scott Hanselman

Tuesday, June 01, 2004 8:46 AM by Shawn Oster    
I posted a fat rant over at Scott Hanselmen's site but the comments here completely justify what I said over there. There are not enough examples of &quot;practice what I preach&quot; out there for people to learn from. I can find a 1000 pages with the classic 3-tier design in some form but try finding quality examples of that in action, with real-world concerns addressed. Theory makes for nice articles but the one-man shop developer that needs to get his product out the door needs some quality production-level examples to kick start him.

There needs to be more articles like Karim Hyatt's out there.

# re: Three/Multi Tier/Layer Architecture/Design by Scott Hanselman

Tuesday, June 01, 2004 9:20 PM by JosephCooney    
In relation to Scott Williams' question and Steve's response...a data row doesn't have to come from a database. I would say you have coupling between your business tier and your data tier. If the data row came from the data tier then that coupling exists anyway. What are the alternatives? You could return a &quot;business object&quot; from the data tier. If that business object needed to travel down to the UI tier then you have coupling between your UI tier and data tier. If the &quot;business object&quot; resides in a seperate third place (not the business tier and not the data tier) then you have effectively split your business tier in half, and there is now coupling between this new half of the business tier and your data tier. That is the way I look at it anyway. One solution might be for the data tier to know about the business tier and construct the business object, but I usually prefer for the business tier to know about the data tier, but not the other way around.

# re: Three/Multi Tier/Layer Architecture/Design by Scott Hanselman

Tuesday, June 01, 2004 10:49 PM by Steve    
Joseph, I wasn't implying that the data row comes directly from the database, but as you mentioned from the data tier. Since data within the data row is accessed using the column names within the data store I wouldn't want my business object loading it's own properties with the data row. My preference would be to have the data tier perform this function (if it had to be either the biz or data). The data tier knows about the data store, and there isn't anything wrong with it knowing how to load business objects with the data it recieves from the data store. You mention that this creates a coupling between the UI and data tier which I'm not sure I see. The UI will interact with the domain model (business objects), not the data tier. Why do you prefer for the business tier to know about the data tier and not the data tier to know about the business tier? I have a lot of different thoughts on this which I'll have to blog, since I'm not sure I'm doing too good of a job explaining the *reasons* I prefer things the way I do. It would also probably be helpful to give some concrete examples to show what I prefer and why :)

Post a Comment

 
 
Prove you're not a spammer: 
4 + 4 =