Web Application Data Layer
I am wondering about the long term benefits (if any) of splitting my web application by separating my business logic and data from my web forms. (i.e. form, business logic, data not in one file, but each in its own class in a different folder by itself or in combination with other similar classes). I like to make everything as modular as possible and do it efficiently, it seems like keeping all the code in one file - in a web form makes it easier to organize and reuse. There are certain functions that are used on the site, for example, managing connections that will be in their own classes and files. I'm new to C #, sorry if I messed up the terminology.
thank
source to share
Separating your code into layers brings benefits that go beyond just C #.
If your data access code is stored in a separate layer, it can be easily configured to work with a different database. Database-based code will be encapsulated in this layer, while clients will work with database-agnostic interfaces. Therefore, changes here will not affect the implementation of the business layer.
If your business logic is stored in one place, you will be able to offer your services to other applications, for example, to serve requests made through web services.
If your code is clean and well structured, maintenance efforts will be supported below. Whenever you need to change something, you will learn where to find the responsible code, what to change, and how to reassure the change will not affect the rest of the code.
As for ASP.NET, not after the separation of concerns has led many projects to become a giant ad block of code - presentation code executes business decisions, reverse negotiations directly with the database, when a suitable business method does not exist, the database receives recorded in many places, the data stream follows several paths that are difficult to trace, changes to one path, not entered by all, will violate the integrity and cause data corruption => Result? An almost imperceptible black box of code, where any changes require more and more effort, until it stalls - the project is "finished". Technical bankruptcy.
We usually overlay our application like this (each of the layers is in a separate solution project and therefore in a separate Dll: What I will always be (first) is to have a layered application
- Presentation layer (JUST UI and data binding logic)
- Interface Layer for Business Layer (defining BL access contracts)
- Business layer implementation (actual logic, data validation, etc.)
- Interface layer for data access Layer (definition of contracts for access to DAL)
- Data access layer implementation
Then you can use some factory to fetch the relevant objects. I would look at some library, perhaps using dependency injection like Spring.Net or Microsoft Unity from MS Templates and Practices.
The advantages are as follows:
- separation of logic where it belongs
- no business logic in the user interface (developers should pay attention to this)
- all of your applications look the same, and therefore developers, knowing this architecture, will immediately know where to look for the appropriate logic.
- replaceable DAL. Interfaces define contracts for accessing the appropriate layer.
- Unit testing becomes easier simply by focusing on BL and DAL logic
- Your application can have many entry points (web interface, Winforms client, web service). They can all refer to the same business logic (and DAL).
- ...
I just couldn't live without it.
source to share