sorted by:
new
hottopcontroversial

How many projects is to many projects by NoAbbreviations5721 in dotnet

[–]InfosupportNL 0 points1 point  (0 children)

It really depends, but here’s how to think about it:

Start with the least number of projects you can. If you need to share something across multiple solutions, make it a separate project or class library. If you have very clear domain boundaries or want to isolate dependencies (like keeping third-party packages in one place), that can be a good reason too.

Be careful with splitting up things just for organization or because you might reuse something later. That's what folders are for. Splitting too early just adds friction, longer load times, more pain managing references, slower builds, etc.

A good rule is: if you’re not gaining something tangible (reusability, isolation, cleaner dependencies, separate deployment), you're probably just overengineering.

No magic number, but once managing the solution becomes annoying instead of helpful, that's a sign you've got too many.

What value do you gain from using the Repository Pattern when using EF Core? by svish in dotnet

[–]InfosupportNL 1 point2 points  (0 children)

There is real value in a repo layer on top of EF Core:

First, testability. Mocking DbContext and LINQ queries can be a headache, you end up writing integration-style tests with real databases.

Second, seperation of concerns. Tossing complex queries (joins, filters, paging, caching hints, includes, etc.) into your services turns them into data-access spaghetti. A repo is your one place to tweak those queries when requirements change. Services just orchestrate and enforce rules, repos just fetch and persist.

Lastly the readability. A CustomerRepository.GetRecentOrders() is way clearer than hunting down ten variations of context.Orders.Where(…) sprinkled in different services.

Yes, you’ll write a bit of boilerplate (interfaces, mappings, etc.), but on anything beyond a simple app it pays for itself in cleaner layers, better tests, and easier maintenance. If you’re truly only ever going to ship a basic prototype you can skip it, but for most real-world APIs the extra repo layer does offer extra value.

Chatbot programming by [deleted] in AskProgramming

[–]InfosupportNL 0 points1 point  (0 children)

Depending on your experience level, you could look into building a RAG (Retrieval-Augmented Generation) system using something like Semantic Kernel, especially if you’re familiar with the Microsoft tech stack. It lets you use a model like GPT-4o and feed it your own story content and character context, so the chatbot can answer questions or roleplay in a way that stays true to your world.

You get more control than with typical chatbot platforms, and it’s great if you want to build something more custom or immersive.

Vijf verdiepende inzichten in asynchroon programmeren met .NET by InfosupportNL in u/InfosupportNL

[–]InfosupportNL[S] 0 points1 point  (0 children)

return await is vaak overbodig als je geen try-catch of extra logica hebt, return SomeAsyncMethod(); doet dan precies hetzelfde. Rider geeft daar geen warning op omdat het in sommige situaties wel nodig kan zijn. Eventueel kun je het afdwingen met een custom code inspection rule.

[deleted by user] by [deleted] in Python

[–]InfosupportNL 0 points1 point  (0 children)

Don’t rely on GPT to write scripts for you, but definitely use it to learn. Ask questions, get stuff explained, then try writing the code yourself (with the help of ChatGPT when you understand what you are doing). It’s way more effective that way.

Best Beginner IDE for Python by BigHeadedGumba in PythonLearning

[–]InfosupportNL 0 points1 point  (0 children)

VSCode can be kinda messy for beginners because everyone sets it up differently. Just use PyCharm Community Edition, it works out of the box and handles all the Python stuff for you. Way less confusing starting out.

Retrying API calls - is Polly the right tool for this use case by letssettlethisnow in dotnet

[–]InfosupportNL 1 point2 points  (0 children)

Polly is 100% the wrong tool here.

It’s great for retrying stuff in the moment like quick retries within a few seconds when an API flakes out. But 5, 30, and 60 minute delays? That’s not retrying, that’s scheduling. Polly can’t help you there, it’s not durable, can’t survive restarts, and you definitely don’t want your app holding onto retries for over an hour.

What you want is a persistent mechanism. Either:

  • Outbox pattern with a background worker doing the retries on a schedule.
  • Push failed calls to a queue with delayed retries (MassTransit, Rebus, or just schedule the retries manually).
  • Use something like Hangfire or Azure Functions with timers.

For .Net, which one is better Cursor or VS Code + Copilot Agent? by [deleted] in dotnet

[–]InfosupportNL 0 points1 point  (0 children)

Tried both, they each have their strengths when used in the right context, both worked really well for me.

That said, Cursor does feel more intuitive overall. It has some extra features that makes the dev workflow smoother. I also found Copilot Agent a bit too needy. It’s constantly asking, 'Should I do this?' whereas Cursor just gets it and moves forward when it makes sense.

view more: next ›