Generic CRUD solution

[beolafsen]

In my solution I have twenty database tables. To handle these tables, I previously had twenty repositories, controllers and services.

After switching to a generic CRUD handling, I have reduced the code to one repository, four controllers + one generic-controller and one service + one generic-service. The non-generic Services and Controllers only handle non-CRUD operations.

The advantages that I see are:

1. The number of lines of code has become much smaller. Probably almost 80-90% less for services, controllers and repository.
2. Since all tables use the same code, hopefully existing code will be tested better than before.
3. I get started with the production of UI code faster than before. For many of the tables, I can start directly with coding Module/Settings without having to program repostory/controller/service.

• Are there any disadvantages with this solution that I don't see?
• Is this Generic solution something that could be done in the framwork? (I know that a change needs to be made to the database tables to achieve this.)

Best regards
Bjørn-Even

[sbwalker]

There are limited downsides to using this approach within custom modules.

The topic of changing the core framework to use this approach has been raised numerous times in the past. At one point a sample implementation was created to validate that introducing a generic repository will save time instead of including a repository for every entity. Based on the sample implementation it showed that the majority of core entities do not conform to a simple CRUD pattern - almost every entity has additional parameters or business logic that require custom methods which do not conform to a standard interface. In addition, one of the main principles in the Oqtane philosophy (https://www.oqtane.org/blog/!/20/oqtane-philosophy) is consistency - which means that core framework needs to use a consistent approach - so it would either need to embrace a generic repository approach fully or not at all. Another principle is backward compatibility and although the Repository classes are technically not part of the public API, many third party modules utilize their methods for server-side integrations. This means that the signature of these methods cannot be easily changed as it would cause a breaking change. And since the repositories are working fine from a functional perspective, it does not make sense to significantly refactor them in an attempt to theoretically reduce the amount of code.

[beolafsen]

Thanks for answering!

I understand that this approtch is not relevant for Framwork, so I just want to clarify some of my views. You don't need to answer. :-)

I can see that a lot of the entities in the Framework have business logic in the repository. Some of my enties also have buisness logic - but I have placed all the logic in the controllers - not in the repository. In my repository I only do CRUD operations - and then it is easier to make a generic repository. I have only one repository - and that is the generic one.

I might agree that from the Framework's point of view, it doesn't make sense to change to generic routines, but for all the customers who use (or will start to use) Oqtane and are going to start creating Modules with associated Services, Controllers and Repositories, it can make a big time difference if they do not have to create these (service, controller and repository) and instead use the generic service/controller/repository available from the Framework.

I'm a little bit unsure how it will affect the customers sw that is allready made. I don't think they will be affected by this changes. They can continue to use their Services, Controllers and Repositories as they are. Maybe they have to addapt to the new BaseEntity class. If they read enties from Framework - they will probably need to do some small changes.

I have no experience with backward compatibility so it is a litle bit difficult for me to judge how it will be affected by switching to Generic Service, Controller and Repository.

[leigh-pointer]

@beolafsen There should be no problem in implementing your own logic for your own modules; that is the beauty of the extensibility architecture.

[sbwalker]

One other item I did not mention in my previous response is related to Services. The default Module template was modified in Oqtane 5.1 so that it uses a dual service implementation approach. This means there is a single Service interface and 2 implementations of the interface - one in the client project and one in the server project.

The client implementation is used at runtime when running the module in a true client/server environment ie. on WebAssembly or .NET MAUI. In this configuration it needs to make an HttpClient call from the client to a Controller on the server... which then calls the server implementation of the Service which calls the repository.

The server implementation is also used at runtime when running the module on the server ie. on Blazor Server (SignalR) or Static Server Rendering. In this configuration there is no HttpClient call or Controller required... it just needs to call the server implementation of the Service which calls the repository.

Based on this architectural change above, the business logic was moved from the Controller class to the server Service implementation so that it is implemented in one location for all runtime flows. The Controller became a very thin wrapper for calling the server Service implementation - providing only the accessible endpoints.

[beolafsen]

Thank you for the update. I will download it and look into it.

Contrinue the good work.

Best regards
BEO

[beolafsen]

Hello!
I have gone through the code regarding Services on Client and on Server, but to be honest, I do not understand how the system knows which Service to use - Client or Server Services? Do you have time to say something about the technique used?

[sbwalker]

The flow is determined at runtime based on which Blazor render mode and interactivity is being used for a site/component.

Interactive Blazor WebAssembly or Interactive Blazor Hybrid (.NET MAUI)

This is true client/server where the Oqtane.Client assembly is running natively on the client device. This means that Services are registered in dependency injection on the client device. In this scenario the Services are executed on the client and call the server API to get data.

Interactive Blazor Server (SignalR) or Static Server Rendering

This is not client/server - it is server-based where the Oqtane.Client assembly is running on the server. Services are registered in dependency injection on the server. In this scenario the Services are executed on the server and call the repository (database) directly to get data.

[beolafsen]

Smart :-) . Thanks for update.