I am just wondering should the presentation layer connects to the Web API layer first then WEB API layer connects to the Application layer?

Let's say for ATM system which has Check Balance function, in my application service layer, I have these codes:

public class BankAccountService

    public decimal CheckBalanceAmount(int bankAccountId)
        BankAccount bankAccount;

        using (var ctx = new AppDbContext())
            bankAccount = ctx.BankAccounts.Find(bankAccountId);

        if (bankAccount == null)
            throw new Exception("Account not found.");

        return bankAccount.Balance;

At the moment, my presentation layer connect to this application layer above. But I think it should connect first to the Web API layer (HTTP methods (GET, PUT, POST, and DELETE))?

  • 2
    I'm pretty sure a web API is part of the application layer. – Robert Harvey Dec 26 '19 at 3:25
  • 1
    Can you provide a bit more context? What do you mean by Application Layer vs. Application Layer? – Berin Loritsch Dec 26 '19 at 3:25
  • Let's say I have a Web API project which has all the Web API methods for CRUD and I have another Application Service project will store application logic. – Steve Dec 26 '19 at 5:09
  • @BerinLoritsch i added some code snippet in my original post – Steve Dec 26 '19 at 10:44
  • @BerinLoritsch i added some code snippet in my original post – Steve Dec 26 '19 at 10:44

As Robert Harvey mentioned in his comment, a web API is part of the application layer. An application layer is usually something that sits between the presentation layer and the business logic, translating GUI actions into/from messages understood by the objects in the business logic (for example, HTTP requests into method calls, and method results into HTTP responses). As its name says, it controls application logic, how the user interacts with the GUI, controlling screen navigation, etc.

However, I'll provide an answer based on your definition:

I have a Web API project which has all the Web API methods for CRUD and I have another Application Service project will store application logic

Think about it, why do you have the WebAPI if you will connect the presentation layer directly to your application service project? Also, think about what kind of messages the WebAPI and the Application layer are handling. Does your Application layer handle HTTP requests directly? I'll assume it most likely does not, but is a library that the WebAPI calls.

So, for your question, I think you will have this setup:

Presentation layer <-> WebAPI <-> Application layer

EDIT: You will often find applications with the following layers:

Presentation layer <-> Application layer <-> Service layer <-> Persistence layer

The presentation layer contains all the GUI elements, the things that handle presentation formatting, all the necessary command objects and actions the user can invoke on the application, etc. It's the part the users see and can directly interact with. Your application might have multiple presentation layers, for the web, for mobile applications, desktop applications, etc. The presentation layer is usually tightly coupled to some presentation technologies like HTML, CSS, JavaScript and ways of communicating with the user, like HTTP, WebSockets, etc.

The application layer is a thin layer that offers services to the presentation layer, maybe some coordination for the interactions with the user, and has the important role of decoupling the presentation technologies from the rest of the application. The user might interact with a mobile app, or a web page, which send requests over HTTP. The business logic of your application shouldn't have to deal with HTTP, or HTML, for example, even though that's how you communicate with the user. So the application layer converts messages back and forward to decouple the presentation from the business code. This way, you can keep the same business functionality and expose it in different ways to the user.

The service layer (sometimes called the business layer) deals with the business rules and logic of your application. It's what your application actually does. It can often also provides a transactional boundary for the persistence layer in case multiple data access objects need to be coordinated to fulfill the business goals.

The persistence layer deals with the data access needs of the application. Similar to the presentation layer, this layer is often coupled to technologies like SQL, the file system, maybe web services over HTTP or SOAP.

There are of course many variations of these. In a 3-tier application for example, the presentation layer and the application layer form the presentation tier, while the service layer forms the application tier (1 - presentation tier, 2 - application tier, 3 - data tier). In some cases, depending on the technologies used for the GUI, the role of the application layer is handled by the presentation layer. In some instances there might be a layer in between the service layer and the persistence layer that decouples the two and converts messages back and forward, although in case of SQL data sources that's usually not necessary because of how database drivers work.

So there are variations.... In your case, the WebAPI looks like the application layer, while the code you posted looks like the service layer.

| improve this answer | |
  • I added code snippet for my application service layer – Steve Dec 26 '19 at 10:42
  • 1
    That code looks more like belonging to a service layer than an application layer. You might want to research some of the differences, for example here. – Bogdan Dec 26 '19 at 11:54
  • 1
    In your case, yes. I'll edit my answer to provide a more detailed answer. There is more about it than this... – Bogdan Dec 26 '19 at 13:27
  • 1
    @Steve: see my edit above – Bogdan Dec 26 '19 at 14:53
  • 1
    @Steve: concentrate on separating concerns/responsabilities and decoupling technologies from your core business logic and then natural layers will form, no matter what name you give them. – Bogdan Dec 26 '19 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.