![]() For instance you can see CustomerEntity class with customer name and customer code. Entity classes are nothing but simple classes with SET and GET. ![]() ![]() The other way of passing data is using the uniform approach using entity classes. Method 2: Uniform way of passing data (Entity classes) If DAL tries to use the middle tier it will lead to circular dependency. In case you are wondering why we cannot use the middle tier classes across layers, do not forget, the middle tier is already using DAL. That’s where we can use the uniform way of passing data, i.e., “Entities”. If tomorrow you need to change your data access methodology from ADO.NET to OLEDB, you need to change across tiers.If developers start using their custom way of passing data (like XML), it will lead to increase in complexity.Because we do not have a uniform structure, we need to always convert from one format to another as we pass through each layer, which can lead to performance issues for a large number of rows.In case your data storage and access methods will not change I think this should suffice. Problems and benefits with Non-uniform way From middle tier it uses strongly typed classes.From DAL to middle tier it uses dataset/XML/datareader (personal choices of developers).Summarizing in a non-uniform way the data is moved to UI in the following ways: fetch customer records return new DataSet() ![]() The final thing is the CustomerDal class which just returns the dataset using ADO.NET to pass the same to the middle layer. With this if we change our data access methodology later, it’s not replicated on the UI.” You can watch the project of my console UI, it has no references to System.Data, very clean, isn’t it? This conversion also ensures that we maintain the golden rule of tiered layer: “UI should avoid directly referencing data access components like ADO.NET, OLEDB etc. So let’s start from UI to DAL.ĭata from the UI to middle tier is passed using getter and setter, below is a sample code for the same.įoreach (DataRow orow in ds.Tables.Rows) This is the first way (probably the most common way) of passing data from one layer to another, the non-uniform way. As you read the article you would understand better why I want two perspectives. We will be analyzing the passing of data between layers from two perspectives: how the data will come towards the data access layer, and how the data will pass to UI. So for now we will keep the scope of this article limited and restricted, or else we need to get into web service, remoting, etc., which will lead to more confusion. Layers are more of a logical separation for your code while tiers mean that those layers are deployed in different physical machines. In case you are confused about layers and tiers, the below diagram explains it visually. This article will try to flesh out the various ways of passing data between layers. In software industry people are pretty clear about the common layers and their responsibility (UI for look and feel, middle layer for business logic, and data access layer for data).īut the biggest confusion or I will say where developers have not come to common standards is the way of passing data between these layers. Layered architecture is the most common way of creating software projects because they bring in SOC (Separation of Concern), decoupling, easy understanding of code, etc.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |