What should layers in dotnet application ?

Question

I am using layered architecture in dotnet (mostly I work on web projects). I am confuse what layers should I use ?

I have small idea that there should be the following layers.

1. user interface
2. customer types (custom entities)
3. business logic layer
4. data access layer

My purpose is sure quality of work and maximum re-usability of code.

some one suggested to add common types layer in it. Please guide me what should be layers ? and in each layer what part should go ?

Answer 1

Layering a web application is a bit tricky. A lot of operations just pass through the business layer, so you tend to feel that it's pretty useless.

One of the main purposes of layering is to keep the user interface isolated from the data storage. In theory you should be able to change the data storage solution without having to make any changes to the user interface. In my experience this very rarely happens, but just having the abstraction gives you other advantages, like keeping details from the data storage from showing up in the user interface design.

Typically three layers are used:

1. user interface
2. business logic
3. data access

Data classes / entities are not a layer of their own, but part of the interface between layers. Typically they are exposed by the business layer to be used by the user interface.

Answer 2

It all depends on the requirements, particularly non-functional requirements.

The answer for a single user interactive application is likely to be very different to a web application needing to scale to support thousands of users.

In general KISS, but avoid hardcoding dependencies throughout the code. Designing for (unit) testability is a good starting point.

If you have no good immediate answer, maybe the answer is not very important (i.e. don't over engineer, and YAGTNI).

Answer 3

I'd suggest you to look at DDD (Evans) first of all and Fowler's app patterns. This will show you the big picture. Number of layers that you have in your project can vary: it can can be 3 or maybe 5. It depends on complexity of your project, your experience and so on. So there is no clear answer how many layers should be. The main purpose of layers is separation of responsibilities: presentation layer is responsible for UI and UI logic, domain model layer is responsible for your business logic, data access is responsible for CRUD operations on your objects and so forth.

Answer 4

It depends on what data access technology you are using.

If you are using NHibernate, I would strongly recommend Repository-pattern along with some dependency Injection.

If you are using Linq-to-sql, you should be using Active Data Record-pattern. In this case you may or may not use dependency injection.

In case of Entity Framework, Unit-of-work-pattern can be used.

Generally I arrange my VS2005/2008 - solution like this:

And, I arrange my codes like this:

namespace MySolution.Entity
{
    public interface IMyInterface
    {        
        int Save(MyClass obj);
    }
}

namespace MySolution.Entity
{
    public class MyClass
    {
        IMyInterface _myDa;

        public MyClass(IMyInterface myDa)
        {
            _myDa = myDa;
        }

        private string _message;
        public string Message
        {
            get { return _message; }
            set { _message = value; }
        }

        public int Save()
        {
            return _myDa.Save(this);
        }
    }
}

using MySolution.Entity;
namespace MySolution.Service
{
    public class MyClassService : IMyInterface
    {
        public int Save(MyClass obj)
        {
            Console.WriteLine(obj.Message);

            return 1;
        }
    }
}

using MySolution.Entity;
using MySolution.Service;
namespace MySolution.UI
{
    class Program
    {
        static void Main(string[] args)
        {
            MyClass myobj = new MyClass(new MyClassService());
            myobj.Message = "Goodbye Circular Dependency!";
            myobj.Save();

            Console.ReadLine();
        }
    }
}

You can put IMyInterface.cs in a separate project named MySolution.Contracs. And, then add a reference of it to the respective assembly.

Please note that, this is called layered-design, not tiered-design.

You can also employ a simple framework for your business-entities like the one used in this example.

And finally employ MVC pattern in your Winforms UI layer. You can get the example here.

And I am not providing any link for ASP.NET MVC, coz there are numerous in the net.

Answer 5

Thanks everyone.

As for as I came to decide is there are different architecture available. Selecting an architect is a decision depending on your team, company and planning. Similarly all architectures has some good and bad points.

thanks