ASP.NET 3-tier / Three-Layer Architecture - How to Separate Interface and BLL

Question

I am currently studying my last year of study in the field of computer science and am working on my final project and dissertation. I will use ASP.NET Web Forms and C # to create a 3-layer project - I cannot call it a 3-level project, since it will most likely never be hosted on anything other than my local PC for testing, since It is designed for uni only.

My main question is:

In my opinion, the idea of ​​3-Layer is that the BLL refers to the DAL, and the user interface refers to the BLL to create a complete separation of problems. However, I made a small mock up of the project, following a few tutorials to get a 3-layer interface, and most basic tutorials still require links between the user interface and the BLL.

For example, in a project I created, which is a very simple e-commerce system for products and categories, I created the Product and ProductDAL classes in DAL, and then the ProductBLL class in BLL. With this setting, using only one database table (now forget the categories), BLL, apparently, serves only as a kind of interface between the UI and DAL, the methods are exactly the same as in the DAL, and only call the DAL version.

The problem is that in order to access the DAL through the BLL, I have to pass the Product object to the arguments of the BLL method, which means to first create a product object in the user interface, which means a link to the DAL from the user interface. Is this the right way to do something?

I can get around simple cases like this by creating a method in the BLL that takes the appropriate fields, for example. strings and ints to create the product object and return it to the AddProduct method. However, when it comes to binding different product attributes to shortcuts in the user interface, I still need access to the Product object.

Essentially, do I need to do loading methods in the BLL to access the properties of the product object? If not, what methods actually go there, can you give me some examples of methods that can go into the BLL in this kind of product script?

Thank you in advance and apologize if this was asked earlier - I read a lot of posts about the three-layer architecture, but most of them are very simple and available only for one table.

Answer 1

BLL, apparently, serves only as a kind of interface between the UI and DAL

This is only because this application is very simple - just the CRUD interface at the moment. More complex applications have business rules that will be encapsulated in the BLL (and not in the user interface or DAL).

I need to pass a Product object into the arguments of the BLL method, which means to first create a product object in the user interface, which means a link to the DAL from the user interface. Is this the right way to do something?

Well, there are several options here:

• You may have a Product Data Access Object (DAO) that is shared between different layers. This object is not a DAL object, but the DAL uses it. It is called DTO - Data Transfer Object.
• You can have several different Product objects — one that will be consumed by the user interface, one BLL, and the other DAL, and display layers for translating between different objects.
• Some combination of the above.

Answer 2

The usual way to separate problems is to start by creating a project called YourProject.Entities or something similar. This contains the definitions of the main class, and you reference it when you need to get a large object, such as a client or product or something like that. Along with this, you have another project that acts as a repository. Depending on the technology you are using, you can either implement something like EF to get your objects from your database, or it may contain methods that directly query your database using direct SQL or stored procedures.

What you should keep in mind is that these projects will primarily operate based on user input. Your users will act and your program will respond. The idea is that the actual business logic is separate from your user interface and data access. You can mix and match these ideas on your own, but what I usually saw in my professional experience is the main constraint on data restriction that is performed on the database access side, and data verification is performed directly when creating objects in An Entities project or in a separate EntitiesValidation project that takes objects as a parameter.

If you do not want to have a separate validation project, you need to keep in mind that you can implement business logic directly in objects using constructors and properties. Constructors can apply logic on inputs before creating objects and use full properties - that is, this ...

 private string myProp public string MyProp { get { // Some code } set { // Some code } } 

instead of this...

 public string MyProp { get; set; } 

Allows you to implement rules when accessing data associated with these properties.

In the end, these questions can be answered in different ways, and I am sure that each answer to this question will give you different ideas and opinions on how best to do this. For me, the two rules that I always follow are DRIED (don't repeat yourself) and maintain the code. Separating the logic from access to data from the design of the object from the user interface, it will be much easier for you to maintain and update your program when this time comes ... even if it is just a school project;).