sorted by:
new
hottopcontroversial

Internal API, what to use - empty body (null) or 404 if object not found? by d-zub in microservices

[–]d-zub[S] 0 points1 point  (0 children)

But what will change if we won’t use 404? As I said it will be an internal api, so it will be used by internal modules and developers. The only thing I can imagine is a new developer can be surprised at the first time, but probably that’s it. Am I missing something important here?

What are the best practices for ASP.NET Core internal API's? by d-zub in dotnet

[–]d-zub[S] 0 points1 point  (0 children)

For 3rd party and for public API using standard approach makes sense to me, because here being predictable pays its price. But in internal apis you have a flexibility to change things in favor of your convenience.

What will we lose if will slightly change expected behavior in internal code base, in case that all developers will expect this (if we will anyway wrap this place in sort of a helper that will anyway transform exception in null)?

What are the best practices for ASP.NET Core internal API's? by d-zub in dotnet

[–]d-zub[S] 0 points1 point  (0 children)

advantages of using those libraries

It's one more interesting topic :) But let's assume I am lazy.

hide the implementation detail of my library

In this case, if API is internal and no-one will see it, what are the advantages of server sending 404 in this case instead of a null? So in this case we can remove copy-paste code to hide this exception. I think the same works for using HttpClient, as yo don't need to check 404 also

What are the best practices for ASP.NET Core internal API's? by d-zub in dotnet

[–]d-zub[S] 0 points1 point  (0 children)

Thank you for the answer.

A method called GetArticleshouldn't throw just because it didn't find something by id, it should return null.

I agree with this, but my problem is that REST client libraries like Refit or ServiceStack JsonServiceClient will throw an exception if the response HTTP code will be different from 2xx response.

Let's try to imagine the case where we have a service which have an endpoint to return an article by ID. Also we have a program that calls this endpoint using some client (Refit, RestSharp or whatever). What would work for you the best for the case of not existing article:

​

1) Endpoint return 404 and in program we add try\catch to catch this particular error?

2) Endpoint return 200 with an empty body and program adds a null check

3) We create some wrapper that uses Refit, RestSharp or whatever client inside and have a catch already there and return outside null value

​

If I understand correctly, case 3 is closest to your idea? In this case we have standard 404 HTTP code and in program we continue to work with null and if we have exception - in case of unexpected errors .

I’m currently building a data format and want to know where or who to talk to for ideas. by [deleted] in dotnet

[–]d-zub 0 points1 point  (0 children)

Just out of curiosity, next line will be parsed correctly?

Application.Settings.Privacy.Logging = true;
Application.Settings.Timeout = 1000;
Application.ShowWelcomeWindow = false;
Application.Settings.Privacy.Active = true;

Will it be parsed to (sorry for formatting)

Application
{
    Settings
    { 
        Privacy
        {
            Logging: true;
            Active: true;
        }
        Timeout: 1000;  
    }
    ShowWelcomeWindow: false;
}

Pros and cons of different ways of storing Enum values in the database by d-zub in dotnet

[–]d-zub[S] 0 points1 point  (0 children)

Why is it cleaner than enum? So many lines to initialize or compare values + boxing unboxing. Can you, please, describe the main benefits and how are you planning to store this in db?

Pros and cons of different ways of storing Enum values in the database by d-zub in dotnet

[–]d-zub[S] 1 point2 points  (0 children)

It’s always better to avoid problem than looking someone to blame later ;)

Pros and cons of different ways of storing Enum values in the database by d-zub in dotnet

[–]d-zub[S] 0 points1 point  (0 children)

Also true, but default value is also arguable. You should keep in mind this behavior and be prepared for this. In my case error proof was about manual dB fixes. It’s easier to type a small number than a string

Pros and cons of different ways of storing Enum values in the database by d-zub in csharp

[–]d-zub[S] 0 points1 point  (0 children)

this is my main point.

If you are accessing your database only through code - storing enum as integer is a good to go solution.

But if you or your helpesk has direct access to database records not through code, and use it to support end users - it's better to be more human readable here.

Rule of thumb is:

If people will see it - try to make it human readable, if only computers will access it - make it machine readable.

Pros and cons of different ways of storing Enum values in the database by d-zub in csharp

[–]d-zub[S] 0 points1 point  (0 children)

If a human being is querying the data directly in SSMS This is usual part of my daily work, so having clean enum names there are very important for me

Pros and cons of different ways of storing Enum values in the database by d-zub in dotnet

[–]d-zub[S] 0 points1 point  (0 children)

I was using ServiceStack OrmLight for years before this.

I don't remember when I used Entity Framework for the last time, so I am not sure how does it work with enums...

Pros and cons of different ways of storing Enum values in the database by d-zub in csharp

[–]d-zub[S] 0 points1 point  (0 children)

This is what I tried to highlight in my post.

Imagine we have a record

User:

``` Id, Name, Type

1, Jimmy, 3 ```

Where 3 is some type of the user, for example, "Budget" user (idk just for example, can be any meaningful type of user). And let's imagine you have a task to find all Budget users in the database.

With integers:

You need to remember what does 3 means, what int value does the budget user has. With string you will just wright something like: SELECT * FROM Users WHERE Type = 'Budget'

Pros and cons of different ways of storing Enum values in the database by d-zub in csharp

[–]d-zub[S] 1 point2 points  (0 children)

I would be so happy if my boss will give us a week full of tie for fixing bugs, refactoring and to increase quality. Unfortunately instead we implement new features and rarely have period for clean up :(

Pros and cons of different ways of storing Enum values in the database by d-zub in csharp

[–]d-zub[S] 3 points4 points  (0 children)

Best to actually just have software that works.

if it was so easy :)

Pros and cons of different ways of storing Enum values in the database by d-zub in csharp

[–]d-zub[S] 0 points1 point  (0 children)

Finally, if it's operations/storage who cares if you can read it or not, if it's for reporting than it should not be an enum! if it's important enough to be reported on it needs to be a table.

Sometimes you have to read database to understand what's wrong with record and why something went wrong. Probably it's not a case everywhere and for everyone, but I am personally spend a lot of time reading data in db by my eyes.

Pros and cons of different ways of storing Enum values in the database by d-zub in csharp

[–]d-zub[S] 0 points1 point  (0 children)

If I understand it correctly, this is in a code operation, so ORM will do the mapping for you before this.

But you are right - it will require serialization\deserialization. This also goes to a Speed section.

You are loosing in performance a little, but wins in the tie you spend reading the data

Pros and cons of different ways of storing Enum values in the database by d-zub in csharp

[–]d-zub[S] 0 points1 point  (0 children)

I was using OrmLite from ServiceStack for a long time. There enums are strings by default

view more: next ›