Newbie: How to structure/layout your solution/projects?

Question

User2006178999 posted
Hi folks,
  i have a simple question about how to layout a common website application. I'm a fan of  n tier design, but i'm not sure how people do this with their .net solutions.

A first i thought of having the following projects listed in the solution.

1. Class library
2. Business Layer
3. Data Layer.
4. Web Site.

Therefore, if i wanted to create a different application (eg. a web service or a winform) i just need to use the dll's from 1, 2 and 3. If i wanted to make a totally new system i can reuse the class library dll and extend that if needs be.

Now my question is, is this a pretty common solution break down? Are other people doing things like this? What happens if we have some business objects that come from a web service? is it bad to put web references in the business layer? What about lazy initilisation/loading aggregations? How can that exist in the class library ... or even more importantly, should that exist in the class library? remember, the class library knows nothing about persistence...

eg.

public class Cat : Animal
{
  private string _name;
  private Onwer _owner;
  
  // ... snip ....
  
  public Owner Owner
  {
    if (this._owner == null)
    {
    // Lazy load owner
    // this._owner == Lazy Load the owner from somewhere.
    }
    return this._owner.
  }
}

and finally, the UI would of course use the Business Layer to do all the actions.

thoughts/advice/links to show me best practices? :)

-PK-

Answer 1

User-503940700 posted

Hi,

Every project is structured in a way which is decided based on the business requirements so there is no golden thumb rule saying this many layers are required. See my blog entry on a smilar topic: http://geekswithblogs.net/vivek/archive/2006/06/21/82624.aspx

Meanwhile, you can have a look at the CSLA.NET framework (source code is free): http://www.lhotka.net/Area.aspx?id=4

Hope this helps,

Vivek

Answer 2

User933406816 posted

You can also check Microsoft's Paterns and Practices

http://msdn.microsoft.com/practices/topics/arch/default.aspx?pull=/library/en-us/dnbda/html/distapp.asp

Answer 3

User2006178999 posted

Thanks heaps guys for your thoughts.

I do aggree that each application we work on is different - so there's no one golden rule of thumb. That said, I was hoping there might be a starting point for some simple applications. I started having a look at the source code for the 'STARTER KITS' but that looked very confussing. For example, the commerce kit was all about making different 'provider' projects and then putting some BLL and DLL into the web site app.

I suppose i'm not after the 'magic bullet' solution, but what solutions are other people doing. For example, Bob says 'with the current project i'm on, we've got 4 projects in the solution, which are blah blah blah..'

I'm trying to see other practices people are coming up with to get an idea of what might suit us. We've done a score of projects in the last 7 years here, but i've never been 100% happy with the solution layout.

Secondly, we have our own business objects which we've developed over time, mainly to suit the market place we're in. (finance industry).

Anyone else have some more thoughts to keep this topic moving along?

Answer 4

User-389939489 posted

Hello PK:

A first i thought of having the following projects listed in the solution.

Well, apart from how we organize the projects, which might be a next step, the most common logical layers for the web application are:

   (user) -> UI -> [ AL -> BLL -> DAL ] -> (datastore)
                   [   -> DTOs        ]
                   [   -> System      ]

• UI = User interface layer (this is what runs on the client-side)
• AL = Application layer (handlers, as web pages and web services)
• BLL = Business logic layer (business logic and rules execution)
• DAL = Data access layer (wrap datastore and map data to entities and back)
• DTOs = Data transfer objects (entities, referenced by other layers)
• System = System services (access to external services, referenced by other layers)

In simple data-driven applications, the BLL might disappear, DTOs might be replaced by datasets and similar approaches, and the System services might also be unneeded.

Therefore, if i wanted to create a different application (eg. a web service or a winform) i just need to use the dll's from 1, 2 and 3. If i wanted to make a totally new system i can reuse the class library dll and extend that if needs be.

Yes, the main and not only advantage of layering the projects is that you can reuse/share. This said, maybe keep in mind that it is most common to reuse/share a data access layer than a business logic layer, because you usually have data in an enterprise to be shared among many different applications, but each application deals with a specific business process and runs different tasks and rules.

What happens if we have some business objects that come from a web service?

Web services exchange data only. It is up to the client to materialize objects back from it. In instance, to accomplish this a .Net client project might reference the same DTOs library as the server project.

I hope this answers some of your questions. For the rest, I would read, read, read, then try, try try, then again... :)

-LV