web app data layer dis/advantages

Question

I am wondering about the long term advantages (if any) of layering my web app by separating my business logic and data from my web forms. (ie a form, business logic, data not in the same file, but each in it's own class in another folder by itself or combined with other like classes). I like to make everything as modular as possible and to do so efficiently it seems that keeping all the code in one file - in the web form makes organization and reuse much easier. There are certain functions that are used across the site like managing connections that would be in their own classes and files. I am pretty new to c#, sorry if I am messing up the terminology.

Thanks

Answer 1

The separation of code into layers brings benefits beyond just C# language.

If your data access code is kept in a separate layer, it will be easy to adjust it to work with a different database. Database-specific code will be encapsulated in this layer while clients will work with database-agnostic interfaces. Therefore changes here will not affect the business layer implementation.

If your business logic is kept in one place, you will be able to offer its services to other applications, for example, to serve requests made via web services.

If your code is clean and well structured, the maintenance efforts will be kept lower. Whenever you need to change something, you'll know where to find the responsible code, what to change and how to assure the change will not affect the rest of the code.

As for ASP.NET, not following the separation of concerns has caused many projects to turn into a giant code blurb - presentation code performs business decisions, code-behind talks directly to the database whenever no suitable business method exists, database gets written to from many places, dataflow is following multiple paths which are difficult to trace, changes in one path not introduced to all of them will break integrity and cause data corruption => Result? Almost unmaintainable code black box where any change requires more and more effort until it stalls - project is "finished". Technical bankruptcy.

Answer 2

We usually layer our application as follows (each of the layer is in a separate project of the solution and consequently in a separate Dll: What I would always go for (first) is to have a layered application

• Presentation Layer (JUST UI and databinding logic)
• Interface Layer to the Business Layer (defining the contracts for accessing the BL)
• Business Layer implementation (the actual logic, data validation etc...)
• Interface Layer to the Data Access Layer (defining the contracts for accessing the DAL)
• Data Access Layer implementation

You can then use some factory for retrieving the corresponding objects. I would take a look at some library, possibly using dependency injection like Spring.Net or Microsoft Unity from the MS patterns and practices.

The advantages are the following:

• separation of logic where it belongs to
• no business logic in the UI (developers have to pay attention to this)
• all of your applications look the same and consequently developers knowing this architecture will immediately know where to search for the corresponding logic
• exchangeable DAL. The interfaces define the contracts for accessing the corresponding layer.
• Unit testing becomes easier, just focusing on the BL logic and DAL
• Your application could have many entry points (web interface, Winforms client, webservice). All of them can reference the same business logic (and DAL).
• ...

Just could not live without that..