What should layers in a dotnet application do?
I am using tiered architecture in dotnet (I mainly work on web projects). I am confused about which layers to use?
I have a little idea what the next layers should be.
- user interface
- customer types (custom objects)
- business logic layer
- data access layer
My goal is to have confidence in the quality of work and maximum code reuse.
someone suggested adding a generic layer type to it. Please tell me what should be the layers? and in each layer which part should go?
a source to share
It depends on which data access technology you are using.
If you are using NHibernate I would highly recommend the Repository pattern and some Injection dependency.
If you are using Linq-to-sql you must use Active Data Record-pattern. In this case, you may or may not use dependency injection.
In the case of the Entity Framework, you can use the work-work pattern.
Typically I install the VS2005 / 2008 solution like this:
And I am ordering 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 link to the appropriate assembly.
Note that this is called layered design, but not layered.
You can also use a simple structure for your business entities like the ones used in this.
Finally, use the MVC pattern in your Winforms UI. You can get an example here .
And I am not providing any reference for ASP.NET MVC because there are many on the net.
a source to share
Layering a web application is a bit tricky. Many transactions just go through the business layer, so you tend to feel like it's pretty useless.
One of the main purposes of overlay is to isolate the user interface from the data store. In theory, you should be able to change your storage solution without making any changes to the user interface. This rarely happens in my experience, but simply having an abstraction gives you other benefits, such as storing information from the data store due to the appearance of the user interface in the design.
Three layers are commonly used:
- user interface
- business logic
- access to data
Data / entity classes are not their own layer, but part of the interface between layers. They are usually rendered by the business layer that will be used by the user interface.
a source to share
It all depends on the requirements, especially the non-functional requirements.
The answer for a single user interactive application is likely to be very different from a web application that needs to scale to support thousands of users.
Generally KISS, but avoid hardcoding dependencies throughout your code. A good starting point is a good design.
If you don't have a good immediate answer, perhaps the answer is not very important (i.e. not over engineer, but YAGTNI).
a source to share
I would suggest that you take a look at DDD (Evans) and Fowler Application Templates first. This will show you the big picture. The number of layers you have in your project can vary: it can be 3 or maybe 5. It depends on the complexity of your project, your experience, etc. Thus, there is no clear answer on how many layers should be. The main purpose of layers is the separation of duties: the presentation layer is responsible for the UI and UI logic, the domain model layer is responsible for your business logic, data access is responsible for CRUD operations on your objects, etc.
a source to share