Cyno

I will frame the question in terms of a specific C# objective that I am working on right now but I imagine the question is a pretty general one related to the Dunning-Kruger effect, in a way - how do you know how to build an application when you don't know all the issues you are supposed to prevent?

There is a message hub and I am developing a consumer for it. The original plan was to just create a few background services that get initialized alongside the application, that have a loop to load new messages/events and then process them.

Some time has passed and it feels like I am knees deep in Wolverine, Quartz, Hangfire, MassTransit, transactional outbox and all manner of different related things now. The potential issues are dealing with downtime, preventing loss of messages by storing them in a separate table before processing them, and everyone on the planet has a different idea on how to prevent and solve them and none of them sound simple and straightforward.

Honestly at this point I don't know enough about which problems are going to appear down the line and if I need to use third party libraries, but I am guessing they exist for a reason and people aren't supposed to just manually create their own amateurish implementations of them instead? But how do you know where to draw a line when you don't know exactly the problems that you are supposed to be solving?
What are the problems with having a table for the message queue over a whole 3rd party library for it, or what's wrong with the MS BackgroundService class? How are you supposed to know this?

I've always approached learning Linux by just diving into it and bashing my head against problems as they come until I either solve them or give up, the latter being the more common outcome.

I wouldn't take this approach with other pieces of software though - I'd read guides, best practices, have someone recommend me good utility tools or extensions to install, which shortcuts to use or what kind of file hierarchy to use, etc.
For example, for python I'd always recommend the "Automate the boring stuff with Python", I remember learning most Java with that "Head first Java" book back in the days, c# has really good official guides for all concepts, libraries, patterns, etc.

So... lemme try that with Linux then! Are there any good resources, youtube videos, bloggers or any content creators, books that go explain everything important about linux to get it running in an optimal and efficient way that are fun and interesting to read? From things like how the file hierarchy works, what is /etc, how to install new programs with proper permissions, when to use sudo, what is a flatpak and why use it over something else, how to backup your system so you can easily reconstruct your setup in case you need to do an OS refresh, etc? All those things that people take for granted but are actually a huge obstacle course + minefield for beginners?

And more importantly, that it's up to date with actually good advice?

I understand the basic principle but I have trouble determining what is the hard line separating responsibilities of a Repository or a Service. I'm mostly thinking in terms of c# .NET in the following example but I think the design pattern is kinda universal.

Let's say I have tables "Movie" and "Genre". A movie might have multiple genres associated with it. I have a MovieController with the usual CRUD operations. The controller talks to a MovieService and calls the CreateMovie method for example.

The MovieService should do the basic business checks like verifying that the movie doesn't already exist in the database before creating, if all the mandatory fields are properly filled in and create it with the given Genres associated to it. The Repository should provide access to the database to the service.

It all sounds simple so far, but I am not sure about the following:

• which layer should be responsible for column filtering? if my Dto return object only returns 3 out of 10 Movie fields, should the mapping into the return Dto be done on the repository or service layer?

• if I need to create a new Genre entity while creating a new movie, and I want it to all happen in a single transaction, how do I do that if I have to go through MovieRepository and GenreRepository instead of doing it in the MovieService in which i don't have direct access to the dbcontext (and therefore can't make a transaction)?

• let's say I want to filter entries specifically to the currently logged in user (every user makes his own movie and genre lists) - should I filter by user ID in the MovieService or should I implement this condition in the repository itself?

• is the EF DbContext a repository already and maybe i shouldn't make wrappers around it in the first place?

Any help is appreciated. I know I can get it working one way or another but I'd like to improve my understanding of modern coding practices and use these patterns properly and efficiently rather than feeling like I'm just creating arbitrary abstraction layers for no purpose.

Alternatively if you can point me to a good open source projects that's easy to read and has examples of a complex app with these layers that are well organized, I can take a look at it too.

Let's say I am making an app that has table Category and table User. Each user has their own set of categories they created for themselves. Category has its own Id identity that is auto-incremented in an sqlite db.

Now I was thinking, since this is the ID that users will be seeing in their url when editing a category for example, shouldn't it be an ID specific only to them? If the user makes 5 categories they should see IDs from 1 to 5, not start with 14223 or whichever was the next internal ID in the database. After all when querying the data I will only be showing them their own categories so I will always be filtering on UserId anyway.

So let's say I add a new column called "UserSpecificCategoryId" or something like that - how do I make sure it is autogenerated in a safe way and stays unique per user? Do I have to do it manually in the code (which sounds annoying), use some sort of db trigger (we hate triggers, right?) or is this something I shouldn't even be bothering with in the first place?

Let's say I have a method that I want to make generic, and so far it had a big switch case of types.

For an simplified example,

switch (field.GetType()) {
case Type.Int: Method((int)x)...
case Type.NullInt: Method((int?)x)...
case Type.Long: Method((long)x)...

I'd like to be able to just call my GenericMethod(field) instead and I'm wondering if this is possible and how would I go around doing it.

GenericMethod(field)

public void GenericMethod<T>(T field)

Can I use reflection to get a type and the pass it into the generic method somehow, is it possible to transform Type into ?

Can I have a method on the field object that will somehow give me a type for use in my generic method?

Sorry for a confusing question, I'm not really sure how to phrase it correctly, but basically I want to get rid of switch cases and lots of manual coding when all I need is just the type (but that type can't be passed as generic from parent class)

cross-posted from: https://programming.dev/post/6513133

Short explanation of the title: imagine you have a legacy mudball codebase in which most service methods are usually querying the database (through EF), modifying some data and then saving it in at the end of the method.

This code is hard to debug, impossible to write unit tests for and generally performs badly because developers often make unoptimized or redundant db hits in these methods.

What I've started doing is to often make all the data loads before the method call, put it in a generic cache class (it's mostly dictionaries internally), and then use that as a parameter or a member variable for the method - everything in the method then gets or saves the data to that cache, its not allowed to do db hits on its own anymore.

I can now also unit test this code as long as I manually fill the cache with test data beforehand. I just need to make sure that i actually preload everything in advance (which is not always possible) so I have it ready when I need it in the method.

Is this good practice? Is there a name for it, whether it's a pattern or an anti-pattern? I'm tempted to say that this is just a janky repository pattern but it seems different since it's more about how you time and cache data loads for that method individually, rather than overall implementation of data access across the app.

In either case, I'd like to learn either how to improve it, or how to replace it.

Was just wondering what's popular nowadays, maybe I find something new and better - what kind of tools are you using to access and manage databases?

I'm personally using Dbeaver a lot but honestly it feels increasingly more buggy and unreliable as time passes, every installation and update has had (unique) issues so far and there's little support. However the ease of use and some powerful, convenient, utilities in it make it preferable to others.

It is a common sentiment that managing dependencies is always a big issue in software development and the reason why so many apps come pre-bundled with all the requirements so it reliably works on every machine.

However, I don't actually understand why is that an issue and why people generally bash npm and the way it's done there. Isn't it the simplest and most practical solution to a problem - you have a file which defines which other libraries you need, which version, and then with one command you can install them and run the program?

Furthermore, those libraries and their specific versions can be stored elsewhere and shared across all apps on a system so you can easily reuse them instead of having to redownload for each program individually.

I must be missing something since if it were that easy, people would have solved it years ago and agreed on a standardized best way, so I'm wondering what is the actual issue and a cause of so many headaches.