BLL, DAL, OBJ and three-layer architecture

My question is three-layer architecture.

My project is briefly similar to below, however annoying me after I insert a new column into my database, I need to update all fields except BLL. In the presentation layer, I created an OBJ, and also inside DAL plus inside DAL, there is an SQL query. I have to update all these fields manually.

If I do this in the β€œnormal” way, I put everyone in the presentation layer and update everything in one place.

Am I applying this 3-layer architecture correctly and what are the benefits of using this layered architecture?

My second question is:

Inside DAL, I collect data through _view. I wonder if I should write another Boboj for each view? I already have a BOBOj class, but it does not contain all the fields.

When inserting data, I have to use my BOboj, however, when I enumerate the data, I use the views, in this case should I create a different BOboj_view class for each view or another? What is the way to alleviate this?

eg; I have 20 views and 40 classes that map to each table on sql server. My views collect tables with different data (this means different objects). Should I create 20 more classes, except 40, which represent the view?

Obj

class BOboj { private int _PId; private string _Name; ....... ....... } 

Gave

 BOboj_DAL { public bool Add(BOboj obj) { using (SqlConnection con = Connect.connect) { string sql = "insert into Persons (Id,Name, ....... ....... } 

BBL

 BOboj_BLL { ....... ....... public bool Add(BOboj_DAL obj) { BOboj_DAL bb_dal = new BOboj_DAL(); try { return bb_dal.Ekle(obj); } catch (Exception) { throw; } finally { bb_dal = null; } } ....... ....... } 

Presantaon layer

  protected void Add(object sender, DirectEventArgs e) { BOboj_BLL bll_= new BOboj_BLL (); BOboj obj_ = new BOboj { Name = Name.Text, .............. ............... }; bll_.Add(obj_ ); } 

Thanks.

+3
source share
2 answers
  • DA objects must somehow represent your database schema and must be strictly tied to database activity.

  • A business layer is a place where you must manipulate data using the specifics of your project logic. Your business object does not always coincide with the DA object (imagine a DA object with two properties Forename and Surname, but for some reason your BO object has only one Surname property, because Forename is never used in logic. When a business changes its mind and they also want to manipulate with the name Forename, you should add it only to this layer).

  • Presentation-level objects must be strictly tied to representations. There should be no logic. These objects should only be used to display actions.

When you try to save this rule code, it will become much more understandable and easy to maintain, not only for you, but especially for your teammates. Easier to extend well-separated code.

Also remember that in some cases, for example, in projects using web services, the fourth level with service-oriented objects may be implemented.

+4
source

From MSDN Article -

The main advantages of the N-level / 3-level architectural style:

  • maintainability . Since each level is independent of other levels, updates or changes can be made without affecting the application as a whole.
  • Scalability . Because layers are based on layer deployment, scaling an application is easy.
  • Flexibility . As each level can be controlled or scaled independently, flexibility increases.
  • Availability Applications can use the modular architecture of enabling systems using easily scalable components, which increases availability.

You have tightly connected layers. Try to make them free.

To begin with, after the solution template Visual Studio can help you -

2010 Layered Architecture Design Guide

+2
source

Source: https://habr.com/ru/post/1484603/


All Articles