Okay people, here\'s another one for ya\'ll:
I\'m starting in the n-tier apps world. I\'ve done some reading on the topic and general advice is that n-tier apps\' object
That's pretty much on target. N-Tier is a bit more complex than N-Layer however, and can be contrasted by asking, "Are your layers actually living on separate physical servers?"
Depending on how complex your Business layer is, you might want to abstract it further between a Business and Service layer. Typically those two are tied very closely and live on the same physical server. The service layer often acts as a Facade to your BLL.
If you're Presentation layer is on the same server, than your ASP.NET or WinForms apps might want to communicate with the BLL without going through WCF services.
Read up on Microsoft Patterns & Practices - Application Architecture Guide.
Your Domain objects should live in their own assembly typically your domain model. According to Microsoft Framework Design Guidelines, it's good practice to name your project assemblies accordingly:
[Company].[ProductOrComponent].[...]
I happen to like this format of name-spacing and generally use:
[Company].[Product].[Layer].[SubLayer].[...]
Here is an example solution using solution folders to organize each project:
In this example, I have a BLL and Service layer. The Service layer provides the actual implementation in a WCF Library while the Presentation actually contains the WCF Web application to host the services. It's always good practice to split up implementation from interface.
The /Client folder can be ignored, I just use that as a sample console app for testing. Any Client applications that consume your service should probably have their own solution or you're going to be managing a huge solution.
As for your data object being transferred over the wire... I'm assuming you mean the classes from your ORM. (Domain Model) You're correct its generally considered bad practice. The solution is using Data-Transfer Objects. You can see from the picture I have a .Dto library. If you're able to use tools like AutoMapper, than I'm all for it, however, adding DTO's to your solution brings with it further complexity and maintenance. I believe Dino Esposito wrote a good article on the subject. Will try to find it for you.
Hope this helps.
[EDIT]
I should note, I'm unfamiliar with nHibernate's capabilities. There might be better solutions for using that ORM. I've only worked with Entity Framework.
[EDIT 2]
Check out Dino Esposito's - The Pros and Cons of Data Transfer Objects