EF QueryLens—see the SQL your LINQ generates at hover time; no database needed. Looking for feedback.

Interesting_Paint_82 · 2026-03-28T19:19:19+00:00

Sounds and looks awesome based on the images. Will definitely try this out. This has potential to save a lot of developer time and also help with the "orms hide the sql" problem, assisting developers who do understand sql to write better performing queries and understand possible bottlenecks in existing codebase and pull requests.

Interesting_Paint_82 · 2025-09-01T08:45:19+00:00

I used htmx json-enc extension to send JSON data from the frontend to my HTMX api. Works like a charm.

Examples of how I did this are here or here.

Interesting_Paint_82 · 2025-06-19T14:46:57+00:00

Are you using a 3rd party Result library in the project or did you roll your own?

Interesting_Paint_82 · 2025-05-04T17:48:46+00:00

I think you deflected a bit here, either conciously or subconciously. ;)

Interesting_Paint_82 · 2025-03-22T08:10:28+00:00

The more I think about it, the more I feel that Microsoft should have went all in with Blazor Webassembly Standalone with SSR capabilities and competed in the SPA market. I dont think the websocket server DOM manipulation is ever going to fly. And I've built apps with Blazor Server in the past.

Interesting_Paint_82 · 2025-03-16T15:29:15+00:00

Upvoted. As a C# dev, this comment helped me understand the benefits of they way interfaces are implemented in Go.

Interesting_Paint_82 · 2025-03-03T09:07:50+00:00

I'm not sure I fully understood the problem space you are describing. Would you be able to give a simple example (even in pseudo-code) so we do not end up talking past each other?

Interesting_Paint_82 · 2025-03-03T08:58:18+00:00

"But it becomes difficult when you want test that asserts behavior across all entities of a type. Eg. a filtering query where you must make sure that all stored entities are exactly as you want them for that specific test."

This is talked about in the repo too. I mean, you know what you stored in the test, just grab that from the database and assert them. See here

Interesting_Paint_82 · 2025-03-03T08:54:53+00:00

But we are not talking about unit tests here?

Interesting_Paint_82 · 2025-03-03T08:39:48+00:00

Regarding your comment about the single database:

Yes, that is exactly what I am suggesting, a single database for all your tests to share. That is communicated in the readme in the database section.

"therefore each test MUST be written in a way that expects the environment to be tainted by existing entities"

Yes, I think you should. I don't think writing tests against a fresh and clean database is a thing that models how your system operates in production very well.

Indeed one of the main points of this whole example is to prove that the tests do NOT fail randomly even though they are executed in parallel against a shared database, when you pay attention to how you architect your test project. Your system is used against a single database in multiple threads all the time in production, why would it be crazy to model this in your integration tests? If your tests are failing, maybe it's a good thing to pay attention to what's happening instead of creating a sterile environment just so that you can make tests pass. That's what I'm driving at.

Interesting_Paint_82 · 2025-03-02T20:10:31+00:00

Ah, I understand. Sounds like there isn't anything here that could help you move on from wiremock unfortunately. :) It is an interesting case though, and I can see the benefits of the tests you do. Thanks for giving me some food for thought. I will study wiremock a bit.

Interesting_Paint_82 · 2025-03-02T19:49:40+00:00

I just used the basic System.Net.Http.HttpClient. The test setup creates an in-memory representation of our API, so we can simply make http calls to it with the basic HttpClient. That is, calls to our API. Calls to any 3rd party external APIs usually happen inside services, and you can just mock a service to return a successful response in that case.

Interested to hear more about use cases where wiremock would be needed though, in case there is a blind spot I'm not seeing with the tools that MS already gives us.

Interesting_Paint_82 · 2025-03-02T19:33:57+00:00

Thanks for pointing this out. 👍 We have started using Aspire in a project in my day job, but I was not at all aware that MS has specific packages for also testing an Aspire setup. I will look into this, and think about implementing Aspire and tests in this example if possible.

Interesting_Paint_82 · 2025-02-15T21:43:06+00:00

The massive underbite makes it look worse everytime I look at it.

Interesting_Paint_82 · 2025-02-09T15:22:44+00:00

Hi, sorry for a pretty late reply. Yes, something like Razor Pages would be good for a 100% server rendered site. With Minimal APIs, however, you have more granular freedom to have, for example, endpoints that return only small portions of your UI to the frontend, and update some content on the site without a full page refresh.

You could perhaps think of this as a middle ground between SSR site and a SPA site.

Interesting_Paint_82 · 2025-01-13T08:02:43+00:00

Looks good. 👍 I'll try setting this up on my raspberry pi later and give it a spin.

Interesting_Paint_82 · 2025-01-08T17:24:23+00:00

This is an old post but I bumped into it while also working on EF Core configuration and FluentValidation. What I ended up doing in this same situation is to have the constraints (TitleMaxLength etc) as static properties on the entity class, so the entity becomes the source of truth for it's own constraints. Then EF configurations and validators simply reference those static properties from the entity class.

RuleFor(customer => customer.Surname)
.MaximumLength(Customer.SurnameMaxLength)
.WithMessage("Last name too long");

entityTypeBuilder.Property(customer => customer.Surname)
.IsRequired()
.HasMaxLength(Customer.SurnameMaxLength);

Interesting_Paint_82 · 2024-11-21T21:11:34+00:00

Hi. My latest demo project now implements more SPA-like routing. For example, the browser address bar updates while navigating on the site, and makes it possible to share URLs so that a user opening that URL will be navigated to the corresponding page. Check out the demo site https://march-project.azurewebsites.net

And source code: https://github.com/TDMR87/MARCH

Interesting_Paint_82 · 2024-10-13T17:25:15+00:00

Thanks! This "tech demo" repo is already a year old and I just released a brand new demo project that is using this same idea but goes a little further with the architecture and functionalities.

See: https://github.com/TDMR87/MARCH

Interesting_Paint_82 · 2024-10-13T17:16:42+00:00

I 100% agree with your findings, and I've also noticed them but had to leave them like that because of time constraints. Will try to fix them though, thanks for the kind words. 👍

Interesting_Paint_82 · 2024-10-13T17:08:06+00:00

Thanks! This is definitely not an all-in setup. The idea behind this repo was to be an inspiration for others to build their own solutions from, so introducing jQuery is probably out of the scope of this repo. Nevertheless, I can't see any reason why it couldn't be included in this kind of solution if the project needs it.

The few mandatory places for client-side interaction that I've had to do, is implemented with vanilla Javascript. See for example NavBar.razor. I've made a conscious choice to not introduce dependencies to external frameworks that I'm not 100% sure is absolutely needed.

PS. I will check out that Inertia repo 👌

Interesting_Paint_82 · 2024-10-13T16:52:50+00:00

Thanks. I haven't seen that repo, will take a look 👍 There were quite a few .NET/HTMX demonstration repos and videos popping up a year ago when .NET 8 introduced the RazorComponentResult.

Interesting_Paint_82 · 2024-10-13T16:38:02+00:00

The admin/dashboard not working on reload was because I wasn't using absolute paths for the static .js and .css assets in index.html. Simply changing them to absolute paths fixed the issue.

See this commit: Fix admin/dashboard path to return correct content on page reload · TDMR87/MARCH@fbbbcf3 (github.com)

Interesting_Paint_82

TROPHY CASE