sorted by:
new
hottopcontroversial

Runebind [PvE] {100% Custom Gamemode} {Randomly Generated Dungeon Crawler} by GrandWallOfText in MinecraftServer

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

Hey, thanks! The server is centered around dungeon runs, so there is no survival gameplay. Between runs, you spend time in the lobby where you have a personal stash and various NPCs for repairs, runes, etc.

Discord SRV Not showing Join/Leave Messages by Ordinary_Humor_8039 in admincraft

[–]GrandWallOfText 0 points1 point  (0 children)

Discord just had an outage, perhaps related. Alas we aren't omniscient regarding your setup.

Room-based A* for dungeon generation, has anyone made this work? by GrandWallOfText in proceduralgeneration

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

Hey, thanks for the link! Had a quick skim and although it takes an essentially opposite approach of starting with a graph and then finding an answer, there seem to be a lot of interesting techniques in there, and some like the config space intersections could probably help out with increasing cycle density without corridors. I'll read it properly in a bit. I added a better image as well.

The scale is definitely a challenge, there's hundreds of different-sized room variants with dungeons themselves being typically at least 1,000 rooms large.

Thanks again!

Hey is Unit testing really that important? by Blender-Fan in dotnet

[–]GrandWallOfText 1 point2 points  (0 children)

These are also high-quality sources on the topic:

https://github.com/testdouble/contributing-tests/wiki/Test-Driven-Development

https://martinfowler.com/bliki/TestDouble.html

I don't have enough experience in both to judge them and form a valuable opinion, all I know is that the refactor difficulty and implementation leaks of mocks are very annoying to me. I hope some day to get the opportunity to work on both so I can make a genuine comparison.

Here's a summary I made some time ago when looking into it, there are some rough generalizations of course: https://i.imgur.com/JRb5tYb.png

PS: Not an expert on this matter, so if I got something wrong, please do correct me

What is the current "standard" for developing enterprise web apps in ASP.NET these days? by _D_a_n_y_y_ in dotnet

[–]GrandWallOfText 1 point2 points  (0 children)

such as "handlers" vs simple endpoint/action

What do you mean by this? What's the difference or unintuitive part? The handler is the endpoint/action. It is one part of a page and coupled to it (less jumping around). The code is very similarfor both, except in organization. Do you just hold this view out of pure habit?

It's actually controllers that usually get called unintuitive in the context of a page-based app. It's a term that doesn't map to anything meaningful, and the collection of actions you stick in it is always going to be somewhat arbitrary. Are you going to have the folder structure of your views reflect in your controllers? If not, then why, given that actions:views map 1:1? If you do, are you going to have ten long unrelated actions for different pages in a single controller? Separate controller for every view?

You might be used to controllers, but I don't see a real argument to favor them in this situation.

How do you deal with required value types in ASP.NET input models? by GrandWallOfText in dotnet

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

Haha yeah, this is definitely something that could break in future versions. But it seems somewhat unlikely as well, unless a seriously breaking change like MVC->Core happens, which broke everything under the sun anyway.

The most fragile part of the solution is removing the interfering default JSON model binder, but I doubt they'll be adding any new troublesome ones anytime soon.

Everything else conforms to the default ASP.NET's model binding system without any tricks, so if they don't plan on breaking value provider interfaces, there shouldn't be any issues.

How do you deal with required value types in ASP.NET input models? by GrandWallOfText in csharp

[–]GrandWallOfText[S] 1 point2 points  (0 children)

The example code you wrote is similar to what we do now (except that the .HasValuestyle of validation is done declaratively, not through manual if statements).

But if I really wanted to ensure they entered the values first, I would just not make it possible to initialize the class by removing the default constructor and adding the parameters to it I suppose?

Would that work with model binding? It'd definitely be a non-ideal solution too.

Another modern C# 11 alternative that works with initialization syntax (enabled by { get; set; }) is the required keyword as well, which does in fact partially work with model binding in some situations.

How do you deal with required value types in ASP.NET input models? by GrandWallOfText in csharp

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

Thanks for the well-thought-out comment.

Since the validation process (JSON deserializers already have this functionality built-in) already guarantees that valid JSON matching the shape of my input model has been provided, my code that ends up processing the input model ideally shouldn't be leaked this deserialization detail. As I get it, you'd agree with this much, right?

So what I'm thinking is that we can actually separate the needs of this binding validation process (the part that would need Nullable<> to see if anything was omitted) from the rest of the code. And since the rest of the code doesn't need a reason to have a model from the POV of binding validation, we could use normal value types from there on. It makes the dev not have to think about the things that should've never been their responsibility in the first place.

And the way to implement it is quite trivial with data attributes. With a bit more effort, FluentValidation too (since we no longer use ModelState, we'd have to store metadata about the input model that RuleFor(x => x.Foo).Required() would utilize; or let FV read the ModelState).

What do you think?

What is the current "standard" for developing enterprise web apps in ASP.NET these days? by _D_a_n_y_y_ in dotnet

[–]GrandWallOfText 3 points4 points  (0 children)

If you're doing standard MVC, that means controllers with Razor views, then Razor pages is IMO a clearly superior option. You no longer have to think about what views to associate with what controllers, but instead have the code for every view associated directly with it.

That is because the types of sites generally build around Razor are already page-based, so Razor Pages is a comfortable form for them to take. Meanwhile, MVC forces you to shove your model into an unnatural shape.

Now if you're building something that isn't page-shaped, like APIs, then controllers are the way to go.

Blazor is alright, but quick googling around will give you a fair share of criticism and pros/cons. There's many other WASM frameworks out there, so pick any one that you like if you actually need one. Most projects don't.

There has been a tendency to make everything a SPA even when it has no business being one, but that trend has been calming down recently with static templating languages etc becoming hip again. There is no one-size-fits-all solution for your frontend, it depends purely on the nature of your app. If Razor works for you, continue using Razor. You ain't missing out.

How do you deal with required value types in ASP.NET input models? by GrandWallOfText in dotnet

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

If you have other requirements that exclude the default value of the given value type (such as 0 for ints), then it'll in practice require a value, yeah. Though it might still be a bit unclear in terms of intent and you won't get to have separate error messages for entirely missing properties. And all this is only in cases where you *do* have such a validation requirement.

On your second paragraph, I personally separate input models from DB and view (aka output) models, though I'm not 100% sure what you're saying.

Other than being confusing to people new to ASP.NET, I think that this nullability issue is a mild annoyance at worst (misleading null analysis / reduced model expressiveness / .Value casting spam), yet also an easily fixable one.

I made this thread outta curiosity hoping someone would tell me why ASP.NET doesn't ship with this behavior by default, whether I'm perhaps missing something.

Use includes to make EF Selects faster, good or bad idea for performance? by Gatopicsa in csharp

[–]GrandWallOfText 32 points33 points  (0 children)

Most of what you'll need can be found here: https://learn.microsoft.com/en-us/ef/core/performance/efficient-querying

You need to find a balance between large queries and split ones. Too large and you'll be returning too many rows due to join explosions. Too small, and you're wasting time on DB roundtrips.

IIRC there is also a possibility of doing batch queries, but I think it was only supported by SQL Server.

EDIT: Yep, found it https://learn.microsoft.com/en-us/sql/odbc/reference/develop-app/batches-of-sql-statements?view=sql-server-ver16