Easy - where should I put my classes

[eramgarden]

Ok, i think i'm confusing myself here..

I want to have a 3 tier app: presentation, business and dataacess.

 

I've read a lot about all 3 and have an understand of how to separate them. Got an example from 15Seconds website.

 

But where do my classes belong to?

I have a "debtor" class: person who owes money with their data like name, address, how much they owe

"collector" class: info about the person who's collecting :ID, phone number, etc

"account" class: this is the company/client who wants the money etc...

 

but what layer do these classes belong to?? should I just create a folder named Classes and inherit from those ??

 

Kinda lost here..i think ineed a big picture.

[mskeel]

It doesn't really matter where you put the classes...it's how you use them that really matters. Do whatever makes it easiest for you, the programmer, to find and reference the classes. File organization should have no bearing on your applications architecture, unless it's easier to think about things if they are organized in a certain way.

 

Based on your descriptions these all seem like business layer classes but without knowing what's inside them it's a little hard to tell.

[Diesel]

You should put the classes aside for a few years and read a book about programming.

[snarfblam]

You should put the classes aside for a few years and read a book about programming.

A bit harsh, no? To be fair, I've been programming for over ten years now, but I've never written an n-teir application, and I wouldn't be sure where exactly to put the classes either. I might not be Einstein, but I'm no moron either. I'd say it's a fair question. The classes have to go somewhere, and it is only natural that one should wonder if there is a specific place they should go.

[eramgarden]

yeah, what's wrong with that question?? Better i ask than mess a project!

 

Thanks mskeel and marble_eater.

[Mike_R]

Well, I don't totally disagree with Diesel, here, the way you've written your question, it does seem imply that you might be in a little over your head. But you've got to start somewhere!

 

Your "Debtor", "Collector" and "Account" classes all appear to be business objects (the middle layer) to me. Beyond this though, I have no experience with n-tiered applications.

 

Since I'm about as noob as you on this, I would personally start small, create a thin-but-functional front end, then a simple class for your middle layer and then a simple database with, say, only one table to be your back-end. Starting small for starters will likely help you see the big picture as to how the full blown application should be laid out.

[Arch4ngel]

I would see what you shown me as a business layer

 

The data access layer could be DebtorCommand, etc...

 

And the presentation layer would be a simple application via ASP.NET or Windows Form.

 

Tell me if I'm wrong.

[ranbla]

You should put the classes aside for a few years and read a book about programming.

 

I think you should stay away from internet forums until your meds kick in.

[mskeel]

I think you should stay away from internet forums until your meds kick in.

While I love a good flame war, let's try to keep posts relevant, all right?

[eramgarden]

and I started it with my question :(

 

Anyway, look at this example :

http://aspnet.4guysfromrolla.com/articles/102302-1.2.aspx

 

Scroll down to : "Fleshing out the Business Object" and there's a pseudocode

there. Now, if this is a business layer..shouldnt that DB connection, data reader stuff be in the data layer?

 

I would think it should be in a function in the data-layer, then that layer would "'return the built-up UserCollection object."

 

Any constructive :D thoughts on that?

[PlausiblyDamp]

I think the terminology in the article is a bit messed up too be honest. Generally I would expect to find database related functionality in a Data Layer and business functionality in the Business Layer ;)

[ranbla]

While I love a good flame war' date=' let's try to keep posts relevant, all right?[/quote']

 

I agree whole-heartedly on keeping things relevant. As you can see from my post count, I am new to these forums and the first thread I read has that garbage from Diesel. Normally, especially as a new poster, I would just let it go, but a brief look at Diesel's post history shows his post is typical of his "contributions", i.e. useless, insulting tripe.

 

People don't come to tech forums to be ridiculed and insulted. It's that type of behavior that kills public forums. The best philosophy is if you don't have anything constructive to offer, then just keep your trap shut.

 

Sorry to derail your thread eramgarden. I am new to .Net myself so the only thing I can offer in regards to your question would be to agree with what mskeel said. The physical location of the classes isn't really that important.

[Diesel]

but a brief look at Diesel's post history shows his post

 

Brief is the keyword. I actually used to contribute.

Anyway, you ask a stupid question...

 

Business classes deal with business operations..ie...anything that doesn't have to do with the internals of the application...calculations and processes that return real world data...Database classes deal with the creation and manipulation of the data.

 

As for the physical locations...why don't you figure out your namespace conventions and create a folder heirarchy similar to the namespace heirarchy.

[eramgarden]

some good examples:

 

http://communityserver.org/files/40/releases/entry516270.aspx

 

http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=4531&lngWId=10

 

http://www.asp.net/default.aspx?tabindex=5&tabid=41

 

Those links are from this thread :

http://www.experts-exchange.com/Programming/Programming_Languages/Dot_Net/ASP_DOT_NET/Q_21832997.html