Design Pattern for reducing quantity of "pass-through" functions in multiple layer solution

I want to know if there's some design pattern for solving this problem.

Problem: We've multiple layers (MVC).

1. Controller =>
2. Project Service (logic proper to the whole service) =>
3. Common Data Service (BLL - common logic to all services for same solution) =>
4. Data access =>
5. DB.

There are many services in the application, let's say: API, Web service, Mobile service, etc.

In this scenario, i want to know if there's some way of reduce the amount of "pass-through" functions that i need to implement (and also create interfaces for testing) in the "Data Service" of each service. The common Data service is the one that serves and resolve the business logic for all kind of services in the application. This means that functions are "Common" to all services in the application. The particularity of this functions, is that they do not add extra logic, they only call the proper method to the next layer.

Example of the application design

Example of code extracted from one of the Data Service (Proyect service)

public IList<TipoDocumento> GetDocumentTypes()
{
    return SEMService.ObtenerListaTipoDocumento();
}

public IList<EstadoCivil> GetCivilStatusTypes()
{
    return SEMService.ObtenerListaEstadoCivil();
}

public IList<TipoContribuyenteIVA> GetTipoContribuyenteIva()
{
    return SEMService.ObtenerListaTipoContribuyenteIVA();
}

public IList<TipoContribuyenteIB> GetTipoContribuyenteIIBB()
{
    return SEMService.ObtenerListTipoContribuyenteIB();
}

TLDR: design pattern for reducing the amount of "pass-through" functions (that do not add no extra logic) in a solution that requires many layers to maintain consistency and encapsulation

I have to print pattern in js

How can I print this using for loop and console.log I tried to print it with only console.log but it's is not a solution of this task ) and I have to use 'use strict'

Print the following pattern:

1

2 6

3 7 10

4 8 11 13

5 9 12 14 15

How to build architecture correctly

I have a task - to develop an application that performs a sequence of actions. Actions can be systemic (sending notifications by mail, entering data into the database), and actions that require human intervention (approval, upload a document). This process will often change and scale, and it is desirable that the employees themselves do this through a visual constructor. The main thing that I cannot understand is how to store the path of the process itself and how to determine which stage is next (perhaps there will also be checks and forks by type - if the employee confirmed the document, then do one thing, if not, then another). There is an idea to store the path as json:

"Steps": [
    {
      "Id": "Step1",
      "StepType": "Notification.email",
      "NextStepId": "Step2"
    },
    {
      "Id": "Step2",
      "StepType": "Employee.approve",
      "NextStepId": "Step3"
    }
]

But I'm not sure if this will be correct. Can anyone have any ideas on how best to implement this or do you already have ready-made patterns?

P.S. Presumably I will implement this in Node.js

Alternative of multiple args parameter [duplicate]

I am working on a design, where I am using var argument. Now the problem is I need to use two different type of var arguments.

method signature

void addInformation(
    final String call,
    final ApiEnum... apis,
    final ApiTypes... types);

As this is not possible. What could be a better alternative to this design.

How to implement design patterns in the spring framework?

How can I implement the design pattern in the spring framework?

It wants to register all implementations as Spring Bean and flexibly change dependency at runtime.

Please let me know if there is a good example of implementing business logic using design patterns in the spring framework.

Thank you for your kindness.

Design Pattern question: removing overuse of boolean function parameters

It's been decades since I've brushed up on the gang-of-four. I've lately been getting a bad smell from some code, and am looking for recommendations on optimal design.

There exists a function that services an API POST by accepting a binary upload, performing various processing on it, and storing a file. Over time, as new requirements have emerged, some of the steps in that function have needed to be skipped, based on the type of binary being uploaded. Over time, the method signature has evolved like so:

First iteration:

public ResponseObject uploadThing(long user_id, long location_id, byte[] file_bytes)

Second iteration:

public ResponseObject uploadThing(long user_id, long location_id, byte[] file_bytes, boolean ignore_azure)

Third iteration:

public ResponseObject uploadThing(long user_id, long location_id, byte[] file_bytes, boolean ignore_azure, boolean ignore_aws)

Fourth iteration:

public ResponseObject uploadThing(long user_id, long location_id, byte[] file_bytes, boolean ignore_azure, boolean ignore_aws, boolean log_to_airtable)

The booleans correspond to newly added conditionals wrapping the related sections of the function. There are multiple pathways into this function, so every time a new boolean is added, all the calling code needs to be revisited. Also, the code becomes less and less self-documenting. Here's an example of it in one place:

ro = uploadThing(user_id, org_id, file_bytes, true, false, true)

If any of the boolean-dependent code is actually triggered, the order of execution is critical. Also there's no information contained in the other parameters that could be used to determine which sections of the uploadThing method to execute - it's purely based on where the particular calling code is.

Some of the things I don't like about this: the increasingly tight coupling between caller and callee, the increasing need to cover multiple spots in a refactor, and the increasing obfuscation of the method call's intended behavior at the point where it's being called. How would you restructure this?

Is asyncronously awaiting a method or subscribing to an event invoked from an async method more efficient (Intermediate Language/Backend Differences) [closed]

First off, context:

I am creating a custom DB using Memory Mapped Files. (Quickly I would like to say to the critic to that statement alone; I am not working on this for anyone but more as, we can just say, a learning experience. I'm having great fun, and learning a lot about lower level memory management and much more already!)

Okay, with that out of the way, my question regards a rather simple concept. Although I am guessing it may boil down to preference. My two primary areas of concern for my design are maximum performance, and security from unauthorized libraries.

With this said, my question is [theTitle][theFormerStatement]:

What are any considerable differences regarding primarily, though not limited to, abstraction, security, modularity, but especially performance. Of course IO is slow, this would be why I'm trying to start my design from the most performance efficient design pattern.

Also, I'm not asking about DB design choices or anything, I've found plenty on that subject, but rather, I am asking specifically about abstract system design options.

For further context to the IL part, I am using C#, but I'm assuming most languages use similar approaches on events and the like. What are the common advantages and disadvantages between builder pattern and event driven patterns, As it pertains to CIL or any similar IL

Update

I am looking for anyone who more thoroughly knows the low level impacts of these design options, if any, even provided otherwise identical data design choices.

For a generic example, if I wanted to write 1000bytes to the filesystem, I would need to, lets say, validate the file exists, if not create it, find the offset to write at, write the bytes, repeat for index file, validate the write by running a test query and comparing to data that was sent by a client (maybe not necessary, but I'm just coming up with fluff example of work to be done), then return the (bool success, int entryIdx).

(Builder) Call a the DB class by its chain of methods and async wait for result. OR

(Event) Subscribe to OnInsert event from DB and then call DB Write method.

it seems that the former would result in constant checks every frame for when the result returns, whereas the event, being a bit more detached by design, would allow the client to do whatever other work until the event fires, and catches the client system's attention to respond to the work.

What is the functional and performance differences in the IL behind awaiting work in a non-server app from client method call, and notifying any event subscribers vs awaiting results from a client app method call.