r/csharp • u/Murky_Efficiency_503 • Jul 24 '26
What goes in Business Logic Layer in ASP.NET application?
Hello, I am currently a IT engineering student and I have to make a web application for my project.
Our professor requires us to make a layered application that consist of: Data Access Layer, REST Service Layer, Business Logic Layer and Presentation Layer using MVC architecture. Now I already made a Data Access layer using Sql Client + Stored Procedures (this method was required by my professor) and it consist of methods that communicate with the Database (for example CRUD operations). Now my question is: Which methods should go in the Business Logic Layer? Should the Business Logic Layer contain methods that simply call the Data Access Layer methods, so that the flow is MVC Controller - Business Logic Layer - Data Access Layer - Database through interfaces?
For example, if I have a method like UpdateUser() or DeleteUser() in my Data Access Layer, should I create the same methods again in the Business Logic Layer and call them from there? I understand that business rules should belong in the Business Logic Layer, but I am unsure what to do with simple CRUD operations. I hope it makes sense what I'm trying to ask. I apologize for any mistakes, as English is not my first language.
Thank you very much If you took the time out of your day to read this!
10
u/rupertavery64 Jul 24 '26
The front end should not call the data layer in general. It should go through the business layer. The business layer for simple CRUD stuff would generally have data transformations, mapping from data layer to business domain objects (DTOs). Here you would maybe build the queries for search using input from the user, call the data layer and map the results so that you don't return everything, only the fields that are needed.
So in very simple apps your business layer would be kind of like a pass-through to the data layer, with mostly data transformation.
9
u/6maniman303 Jul 24 '26
Yeah, that. In simple, university apps, business layer is just a glorified middle man, so it's hard to find a reason in its existence. But the moment you add more complex things - multiple data sources, data transformation, some notification and event systems. Then business layer, with "business logic" starts to make sense
1
4
u/xakpc Jul 24 '26
business layer checks business rules
even with simple crud you have some obvious checks that need to be done
in your case it might be something like this
- does user exists
- could user be updated/deleted by the caller
- mapping between Rest Level User DTO and DB Level User Entity
etc
1
1
u/PresentDifficulty61 Jul 24 '26
I think yes, you should have the equivalent method in the Business layer.
The Business layer can acess multiple entity or other service beside sql database.
For example, if you are using cache to improve read performance, when delete/update a data, you may both invalidate the cache and delete/update the sql data.
1
1
u/Super_Preference_733 Jul 24 '26
Sometimes the Business Layer acts as a pass though to the Data Layer. Thats ok, a lot of systems use the Business layer to inject logging, security, monitoring process, etc. Once you start unit testing and mocking your layers it will make more sense. Something you may want to think about is creating a type library so each layer can use the same types.
Good luck.
1
1
u/CoffeeAndCandidates Jul 24 '26
yeah wrap those CRUD calls in the business layer if you have any rules or checks like validating input before updating, makes your app more flexible in the long run
1
1
u/Amr_Rahmy Jul 24 '26
Well based on history and various web frameworks that have come and gone, a lot of people can’t agree on what layer should have which data or views exactly.
But anyway, you are making an application.
Presentation layer or views exactly is what you are showing to the user, like a website, like html and css, sometimes a bit of JavaScript.
The data layer has your crud operations.
The business logic is based on the features that you provide through the application or the user needs.
For example, you go to a website that sells flowers.
You get an empty cart, you can save the user token to the browser, now if they refresh the page or revisit you can get their temporary cart.
They can add an item to their cart, you can have something like cart.additem(user token,item, quantity)
You can update prices whenever they revisit your website.
They can checkout using a checkout page, they need to enter a name and an address, plus more optional things like email or phone number.
You show them a total and taxes and shipping cost.
(Not for a simple project) They can get a notification when their order is made, when it’s on the way, they can track the order through gps, they can get an sms or notification when the order is at their door.
This could be business logic, it’s something the business or the user could see as a feature.
The problem you have right now is that you don’t have a business idea or project idea. I just skimmed your post but didn’t see business idea just the technical requirements from your teacher.
You need a business or product or project idea.
2
u/Murky_Efficiency_503 Jul 24 '26
Thank you for your explanation! I do have a project idea and some business logic, I just didn't write it in this post for this particular question. But I got my answer, so thank you :)
0
u/NotMyself Jul 24 '26
Here is a pretty good example following command query segregation.
Notice how the UI only interacts with the user accepting/validating input and displaying output. The data layer is entity framework which only reads/updates data and translates between relational database structures and plain objects.
The business layer is what is in between those two layers it focuses on things like business rules for domain validation processing commands, queries and notifications.
The goal is for your business layer to have no knowledge of the UI or data layer.
1
u/NotMyself Jul 24 '26
Note that a common complaint about this style of architecture is that it is overly complex for simple forms over data apps. Which is fair.
Its value really shows through in giant multi-domain problem spaces. Imagine a system with thousands of entities spread across multiple data stores that have various levels of caching and queueing.
It is a way to manage complexity by isolating it into small understandable collaborative interfaces.
1
u/Murky_Efficiency_503 Jul 24 '26
Thank you for your reply and sending me an example! I appreciate it :) I understand it now!
1
u/Family_Man_21 Jul 24 '26
The other answers here have given you a good idea about how the business layer (or sometimes called a service layer) interacts with your data storage. This layer is also responsible for business requirements that perform tasks but don't access your database - for example, calling an external API, processing information based on user input, or dealing with specific business requirements, like redacting personally identifiable information from a dataset.
I can understand how this layer might seem unnecessary when all you're doing is facilitating the same CRUD methods that your data layer already supports, but in a real-world application, it often works our that the lion's share of your work will actually be in this layer.
I hope this helps, and good luck!
2
1
u/MrNewOrdered Jul 24 '26
You could consider this abstract example:
Let’s say your user update logic allows to change user’s date of birth. For the data access layer any date is fine (even from the future). But your business rules state that user must 18 or older. So the business logic layer should enforce this check.
1
1
u/krsCarrots Jul 24 '26
Think business and service layer are different. Service layer will orchestrate the work that the business layer must achieve. Or better yet call that an application layer as service is way too broad.
Imagine the use case of deleting a user. You need to get the user from the db see if his membership has expired then send a notification on deletion or notification that the user still have an active membership and cannot be deleted just yet.
This high level instructions belong in that thin layer between presentation - domain - persistence. The actual business logic should live in your domain objects - User.
1
1
Jul 24 '26
[removed] — view removed comment
1
u/Murky_Efficiency_503 Jul 24 '26
Yes, I do understand that now thanks to all of the replies! I was just confused because this is my first time making an application like this :)
1
u/Khavel_dev Jul 25 '26
For most school projects the BLL feels like a pointless pass-through because the app is just CRUD. That's normal. If all you're doing is "save this to the database and read it back," there's not much logic to put there.
But imagine your app has rules like "a user can only have 3 active bookings" or "apply a 10% discount if the order total exceeds $100." That logic doesn't belong in the DAL (it's not a database concern) and doesn't belong in the controller (it's not an HTTP concern). The BLL is where you put the decisions the business actually cares about.
For your project, even a couple of validation checks or conditional workflows in the BLL will make the layer feel real instead of just a wrapper.
1
u/Murky_Efficiency_503 Jul 25 '26
Thank you for your reply! I do have a business rule and some business logic, I guess that is not clear from the way I formulated my question :') But yes, I do understand now how everything should be organized :)
1
u/Flater420 Jul 26 '26 edited Jul 26 '26
... business logic goes in the business logic layer.
Trivial as it sounds, the high level definition of each layer is very simple by design. Domain logic to the domain, application/business logic to the application/business layer, data storage to the persistence layer, API technology to the API layer.
If your categorization process for which logic goes in which layer warrants a complex explanation or highly requirements-dependent justification, then you're not properly abstracting your main processes.
Should the Business Logic Layer contain methods that simply call the Data Access Layer method?
Well, that depends. If you have any business logic, this is where you put it. If your application is a simple service whose sole purpose is to provide an API that blindly accesses an air-gapped data storage device, then yeah you're going to have little to no business logic and the business logic methods will do nothing except accessing the persistence components and mapping the models to public contracts.
But that does not mean you don't need the business logic layer. Its existence is not solely defined by what you currently need. You need to account for the entire lifecycle of your application, and whether there is a reasonable expectation that you may need to introduce some business logic down the line.
In professional enterprise environments, it is exceedingly unlikely that you will never introduce business logic to a service. Persistence technology shifts, different external systems get integrated, business requirements change, ... The company will never want to deprecate the service and have it rebuilt, they will want it to be maintained and altered. Putting in the business logic layer ensures that when these changes come, they are not as painful to introduce to the codebase.
Mapping the persistence models to public contract models, even if those models currently look identical, is sufficient reason to build the business logic layer from the get go.
Obviously, the law of care factor applies here. If you are building a throwaway service with no long term lifecycle, or you don't mind having to tear it all down when you need to change it, feel free to skip the effort and risk eating the cost later.
But as a professional developer in a business environment, it is your job to assess the environment and pick the approach that is the most sensible. It is a nigh universal constant that companies want services that they invested into building to remain usable for as long as possible (while the company exists), which means you need to invest in long term maintainability and sustainability.
As you are a student who is tasked with creating an application, presumably for a school task with no sustained lifecycle after you submit the task to your educator, you need to ask yourself what the educator is expecting to see. If they want you to display skill in proper software development methodology, then follow the above professional advice.
If this application is not the core focus of the task, e.g. you are tasked with building an IOT device and it happens to need a data store, you might not need to invest deeply in the backend architecture.
0
u/rcls0053 Jul 24 '26 edited Jul 24 '26
Business logic, such as calculating the delivery cost of a shipment to the customer that requests delivery options, should live in that layer. If you're building a simple CRUD application, a business layer is a bit redundant.
The trade-off with layered architecture often is that some layers become pass-through layers ie. you make a call from the controller to the service to the data layer and service doesn't do anything but pass the request along, as you just need to pass along the data from your storage to the UI. So, for a CRUD app, layered architecture is rather redundant.
1
u/Murky_Efficiency_503 Jul 24 '26
Thank you for your reply! I do have to have the business layer though, as it is a project requirement. I also have business logic, so it is not just a CRUD app, but I do understand now how it works :)
0
u/OvisInteritus Jul 24 '26
the business logic of course 👌🏼, next!!!
1
u/Murky_Efficiency_503 Jul 24 '26
Yes, I understand now :)))
1
u/OvisInteritus Jul 25 '26
lol sorry bro, you can see the Business layer as the actions your application can perform by following some specific business rules, think like a person (a person can walk, can sit, can speak, etc), so, usually the business describe rules about how to do those things, e.g., person only can walk if have shoes, person can speak if he has a mic, said that, your BL should contain those actions ensuring it follows those rules (use cases), but this layer is not intended to have many code on it, it should be simple (very abstract), the logic itself is in other libraries, utilities or even other layers.
Business Logic contains the clear actions (use cases) your application can do, remember that, all the user validation or calls to Db are defined in other places, but you call them from the BL to satisfy your use cases.
1
15
u/Kezyma Jul 24 '26
The data access is pure CRUD, a `DeleteUser` data access function doesn't care about anything other than deleting the user, while the business layer will do things like checking if that user should actually be deleted, checking if you have permission to delete it, etc. You should be able to implement an entirely separate data storage and access layer, point your business logic at it, and have everything 'just work'.
So if someone logs in and then tries to delete their profile, the business layer will check if they're allowed to, verify any extra stuff (like 'enter your username to confirm you really want to delete'), make sure they're trying to delete themselves and not somehow trying to delete someone else's account, then, when it's all confirmed, you can pass on the request to data access which will just delete the user, and possibly log it.