How CRUD Mentality Ruins Your App
Вставка
- Опубліковано 2 січ 2024
- We mostly think our applications in terms of CRUD. However, a CRUD mentality will for sure ruin your application on so many levels. In this video I will share with you an example on how CRUD mentality might ruin your app and how moving over to a task based mentality might make your application better.
#dotnet #programming
Join this channel to get source code access and other perks:
/ @codewrinkles
✅My other channel: / @danpatrascutech - Наука та технологія
I don't know, this approach requires a drastic change in user experience, which we don't have control over most of the time as developers.
Great video as always!
I don't agree that it requires a drastic change in UX. As mentioned in the video, if you go to Facebook, Linkedin or any other major app out there and take a look to how they handle large updates (like the profile page) you'll see that there are tons of different sections that contain a maximum of 2, 3 fields to be updated at once. What I want to point out with this is that the users are already familiar with this experience because they encounter it day by day on all major apps they are using.
I agree that we can't always use a step-by-step form UI. In real applications, we try to minimize the number of steps for the users.
I guess it depends on how the information is organized on the screen(s). In the case of multiple updates on one screen, I can see a scenario where the user makes several changes across various portions of the update and only hits a single Update button, and the other update(s) would not be triggered - although the user may think they have.. There may be a need for some underlying logic to sense changes that have not been submitted and remind the user to make those other updates.
Another great video! As always useful and very clear! Thanks very much for your effort!
I'm glad you enjoyed it!
Super! Thank you for this Dan!
My pleasure!
whats the name of the font you using in rider? its very clear
Thanks for this. It's something that I'm struggling with in my legacy desktop codebases. Sometimes I feel like if I were to re-design the whole user interfaces will be less work than trying to update the whole systems. Not only that, but user experience is a huge obstacle. Users are not keen on moving to different screens that they are not used to. They complain about increased work in terms of completing an update vs. So, in summary, it's best to start with a task-based UI for complicated business logic rather than trying to fix it later on. Thanks again.
A legacy web app is where we also had this problem at work. Fortunately, we managed to convince the customer that this change is necessary. And they are extremely happy now as the benefits of a more performant and extensible app hugely outnumber the drawbacks of users needing to get accustomed with a slightly different user experience. I'm sure not all decision makers would be that easy to convince.
I constantly follow your videos. It is very helpful to become a better engineer. One question, though - let's say the user has to update the address, name, city, etc. You have to make 3 database calls. Isn't it costlier instead of having one database call to update all three at once? Just thought of checking....
This is something I always try to introduce and explain to the team, but almost always the response is that uesrs won't get it/like it. As a developers we should strive to create sustainable apps, this is definitely one way towards that goal. My suggestion is to split the actions across the tabs when possible, makes the UI clean of all the buttons and it is intuitive from the UX perspective what action you're about to perform. Thanks for the video, keep up the great work! 😊
What would you do then to make the user happy?
Having too many buttons would not make the user confused and cumbersome to click around for each update?
If I was the user I would be utterly annoyed.
I have a similar app at work with the same thinking.
Buttons everywhere and I get so annoyed.
Great content! Thank you!
Hei nice video, I wonder if we can put all the actions that a user can perform inside a model instead of putting it inside a service?
Thank you! But If we have a lot of properties ,we will have a lot of Endpoints/Methods...
Also , maybe there is some way to improve EF when we updating user in one method ?
Like AsNoTracking() or something like that ?
When you do updates you can't use AsNoTracking() except if you are willing to manually add entities to the tracking engine, which I wouldn't recommend. Also, you don't need to have an update for each property. You can have updates on 2, 3, 4 or a limited number a properties at once. I usually group those properties according to logical boundaries (basic information, location info, preferences, language and regional) and so on.
Understand,Great.Thank you!@@Codewrinkles
I wonder, if the "different UX" or "save with 1 click" issue can be addressed with just the frontend having to group all those small API calls into 1 under 1 button? :) Yeah, that's maybe N amount of API calls, but at least there is an alternative for the user. Also, I had the idea of "save as you finish typing" kind-of approach, with visual feedback to the user. (But this wont work, if you are adding/deleting a relative). But I like the approach. Thanks, Dan!
If you sort of like mediatr the controller calls away. You can have a save all button and still make these little blocks. I would see room for that adjustment just fire the right commands, you can even use your transaction example in the pipelines for ex.
I don't understand what you mean. You would still have one single handler that does exactly what the service method does. So we would have the exact same issue
@Codewrinkles Yes I see now. I just thought you can have these non spaghetti concrete blocks and still make something that uses them all together like a save all handler calling others but I like this untangle idea. It is funny we have this same problem at work too so thanks for pointing out.
Everybody has this problem, but not everybody recognizes where the problem is. Also on the project at work it all started with "we have performance problems with EF Core". And then when I looked into the code, I realized you can't avoid having problems when you're doing huge updates all at once. Thanks for watching and for being a member.
@@Codewrinkles Thanks for making them. Yes that same sentence about performance I hear at work so good topic.
Nice video. Thanks for sharing your insights. I have a question that is not directly related to the topic of the video. Would your UI (I assume you are using razor pages or classic mvc) use the service class directly or call the API over HTTP?
I think that doesn't really matter. You could even have an SPA and an API behind. Or use Blazor. Or HTMX. It wouldn't really matter.
How would you sell this approach to business/UX people? I already picture them saying that users don't like multiple "Update" buttons.
I sold it to them exactly the way I mentioned in the video. Showed them all the major apps out there that have all implemented this type of UI. The argument that "users will not adopt it" doesn't stand since all users already use this type of UX heavily in their day to day lives.
This approach also mixes very well with htmx
You are probably right :)
line 31 says email == email, great lesson
Oops. Good catch! Thanks
isn't it just the Kiss principle that we apply here...??
I think this is a better approach until a customer says they want a full update and then the big endpoint has to be implemented and now atomic audit log tracking needs to happen on the big update 😢
In a lot of cases, customers can be convinced with solid arguments. If not, then, well, it's his choice. I'll also make sure to send an email outlining exactly what problems they will face with the app in the future because of this choice. Just for the record.
you have lost a lot of weight. Respect!
Thanks. Indeed I have and I plan to continue :)
What about the OO-style of doing things? Just put the update logic in the entity and you have dealt a lot regarding separation of concerns. No mocking required when testing.
I think this is a poor example for the thing I imagine you want to demonstrate. Updating fields separately is in my opinion only justified if the data belongs to a different module or an entire different backend in your application.