With everything you've learned in the past 2 years, is there any chance you could redo the video you posted on the 10th of december on 2019. The Unity Code Review, using the same code. But apply everything you learned in the past 2 years (if anything changed). Would be cool to see how your refactoring evolved over that period.
Hey Charles, love the new format and the new content you've been pushing out. I also think there's a bit of room for improvement compared to your older videos. I think the videos might be a bit too short since they rush through some key things. For example, you say "All our problems are solved" but you don't explain how or why they are now solved. I think it's because the unit of work makes sure all the repositories are updated in tandem every time they are changed, but its not super clear in the video, why delegating the save fixes everything.
Just elaborate a bit more, how does the unit of work solve the opening-streams problem? How does the unit of work fix slow data access? it seems like it's just adding a step that forwards a call to the original code. I think the real solution is from the "little cleanup" that you mentioned, (calling one save vs two), but this happens so fast it's super hard to follow. I think stressing this step might be the most important part of the 2nd half of the video, but it's kind of glossed-over.
@@thebebinator I have to agree, this was the first time that I have actually physically hit that Dislike button on any of these videos by InfallibleCode. I know these patterns well, as I have used them for 20 odd years in Web Development, but even I was left with WTF did you just cut the most important part of this video out of the video!
@@thebebinatorI think it's not only that what you mentioned, Charles use 'await' in 'UnitOfWork' save method. This also changes how save works. Will read tomorrow what it does and try to explain it here
So 'await' have nothing to do with 'UnitOfWork' principle itself. 'await' is just a keyword used when you handle asynchronous operations. Seems main reason of 'UnitOfWork' was incorporating saving data into one place. Similar to one big transaction instead of multiple smaller ones. As Charles said: 'UnitOfWork' keeps track of every changed that happened and write them all in same time when you tell it to. So +1 to explenation by 'thebebinator' and +1 to request of explaining it in more details in video.
Yes that is because the original problem was that an exception might occur in between the two calls to save, causing only the first one to be called and therefore the data would be corrupted, the player would have the item and loose the gold but the shop would not have the item removed nor gold added. Often you would code this as an 'validated transaction' meaning that all operations of the transaction must be completed successfully, otherwise all changes must be discarded or partial changes rolled back. For example you could stor the state of the repositories before each change, the try to make the change and if an exception occurs catch it, restore the state to before any partial changes of the transactions were made. The unit of work kind of encapsulates this because the player and items are part of the same data context, but it is not explained clearly enough in the video, and I think the video glossed over this fact a little too readily. A different way to think of it is the totality of the changes of the transactions written to a buffer which is flushed all at once at the end in the save call, due to it being called last everything before it must have been successful. The data context is a representation of the data into memory, modfying it in the transaction and the writing the full state of the context back to the source, if anything fails the transaction the datacontext must be discarded and reloaded before trying again since it contains and invalid state, this also means that sharing data contexts can be dangerous if you are doing transactional operations.
Didn’t know your channel before, but credit for the relaunch. This high level concept stuff, understanding how lower level coding concepts fit into overall projects, is valuable. Thanks.
Im not sure if this is way to go, its web dev pattern and orm-s wich use it are known from being slow. If you build for example server side of game then you can get way better result with one instance that will do direct queries in async way by prepare statements / stored procedures without repo / uow.
I think it still makes sense to look at something like atomic transactions, where either all steps are computed and stored, or none (in case of an issue). But I agree, it heavily depends on the use case. Not sure how this is usually modelled though (as I have usually just done individual put/post/delete requests) with a client/server architecture. Maybe there is a post request to a certain url with the relevant information in the payload (player id, store id, id to identify action = purchase, amount of money transacted and item[s] that are bought)? On the server side of things, what you mentioned is probably faster yeah.
This channel is exactly what I needed. Most GameDev channels are good for design or marketing but few have good coding topics. I can literally see how my code gets worth by making games and especially GameJams. It's a whole other thing working as a normal developer outside the gaming industry. Often when I see GameDev code I want to punch the creator...and also often I recognize my code is the same crap and being a solo dev I have no one to blame for. I'll definitely watch your videos regularly to see common patterns used in GameDev. PS: Sorry for ranting, but today is day 3 of refactoring my own code xD
I tend to create a base class that inherits from scriptable objects for persistence (during gameplay) that knows how to interact with a separate JSON serialize/deserialize system and then a system that can either save locally or push those JSON files to a backend server.
I'm using Phaser for HTML 5 games, but this is still very helpful. As a beginner who's past the point of just syntax and applying the concepts from zero to real deployed game, learning about structuring data and systems is very insightful. Thanks!
Great video! There seems to be some heavy compression at points in the video though, noticed it mostly at 8:26. It hurts a bit when the visual presentation is so well done haha.
Interesting pattern. I wish at 10:03 instead of just calling save on the data context you showed first changing the in memory values. when the video jumps straight to the conclusion, i was left puzzled. We put an abstraction layer between the service layer and the context.. but the abstract was just delegating with no additional steps. I had to rewatch parts of the video to realize you mean to put more logic in this layer but didn't for speed in the video.
The difference is that he had a Repository implementation for each individual type (shops and players) that he then saved progress to, and the UnitOfWork captures an entire transaction of all the changes made to all different repositories, which then is attempted to be saved at the same time in the end. Of course, you could implement some rollback functionality if it failed and so on, but it still has a different function. I don't like it very much though, because the implementation depends on knowing that the repositories are both using the same DataContext object as we're referencing in the field. And I agree that it felt very rushed in the video.
Hello Charles, how about retreiving the sprites and other resources of the shop items? Let's say I want to download song item. They will have a cover and the actual audio, the repositories will download the items, how about the cover and the music clip to play? Should I store it in the item as a url string and after I will have another web request to download it? Thanks! Amazing content btw, I just subscribed to Patreon! Can't wait to see more!!
Unit of work sounds alot like Transaction in enteprise software. All the changes made within transaction will be persisted in the end, and if any error occurs then in general all the changes are dropped and database remains unchanged.
Huh. I've been using he repository patterm without even knowing it. Was something I came up with myself. I call it an 'interpreter' that interpretes the raw data from the source. Most of the time this is essentially read only (server data) but I also use it for player preferences and other save files where he interpreter is also responsible for saving the data if it changes. 3:42 nice yeah. Mine are abstract too. In an early version they were interfaces, but I was using scriptable objects. You can serialize interfaces with Odin Inspector but this breaks unity cloud build for some reason (something about the AOT compilation process). I wound up using Abstract serializable classes to base the scriptable objects from.
Loved the content but I still fell pretty lost as you never showed where the other persistance objects where referenced, also how did you populate the shops Repository with the shop and ids. So many other questions were raised by the end of the video that it feels a bit incomplete
Amazing video. I think Unit of work is a pattern I should explore outside of the Unity too. When working with data bases and object relational mappers, it seems like this is always properly implemented, but I never thought about designing such a system myself. Learned a lot in this video.
you should change the description from: "Download the project at... " to: "Become a Patreon to be able to download the project at... " It is misleading information! I thought it would be a github link, but your post is locked. Nice video though. Cheers.
Hello! I know this is random, but what boilerplate text do you use for new Unity scripts? I seem to remember you talking about it in one of your videos, but I can’t remember which one
Could you make a video about metworking solutions? There is MLAPI, Photon Pun2, the upcoming Photon Fusion, and probably some peer to peer stuff through steam
When using JSON files to save data in, does Unity hide or obfuscate it after the build? I'm worried that people can open and modify the data values (give themselves 1M gold, for example). Is it safer to use Scriptable Objects?
No - it is just json. ScriptableObjects are not an alternative because they're not meant for persistence (changes there will be lost once the game is closed). But you could use a different way for serialization like the class BinaryFormatter. Then the file is less readable (but ofc still modifiable).
Like MrTomateSalate said, it's just a regular json file - if you want to protect it from user changes, you can add an encryption step when saving and an encryption step when loading. With that said, anything that is only on the client side is technically unsafe, players might be able to reverse engineer the relevant logic for encryption and decryption. But it should keep most users away from accomplishing that.
@@matthiasmax2849 Yep, there's not much of a point to prevent save state adjustments in purely single player/offline games. If a player really wants to do it, probably better to make the process not unnecessarily complex.
Behold, that the JSON serialization is humanreadable. If you want to use it in a released game on the players harddrives, use a symmetric encryption (e.g. AES) before writing the bytes.
This was an example. You don't need encryption if this was for a offline-only game. But the for an online game, the data source would obviously not be a JSON file stored on the client's computer. It would be a connection to an API that handles authorization itself. Also it doesn't matter whether something is human readable, if the data doesn't store private information (i.e. passwords, keys, etc.). Rather, it should ensure integrity, such that the data cannot be changed without the private key.
@@dealloc if you have your game state in a JSON stored on the client, it is even easier to hack your game than with a cheat engine. Just a thing i wanted to point out.
...any particular reason except "it is the default when making new C# file from unity", why your DataContext and Repository classes inherit from MonoBehaviour? Because to me, they seem like something that should inherit from nothing, and live as a pure in-memory object in a property of your global GameManager object, or something like that.
I don't see how the UnitOfWork class changes anything? It's just a wrapper for the DataContext? It doesn't ensure saves are rolled back if an error happens. It doesn't do anything?
It ensures separation of data and functionality. Its intent is to be a pattern that solves this particular problem. Not by itself to ensure datasafety. But if you want datasafety you can now easily put your implementation of how you want to handle these cases. If you want to only handle it on the business logic's side you don't have to make any changes to your data side and vice versa.
@@Sproeikoei Doesn't make sense to me. There is literally no difference between between DataContext and UnitOfWork. DataContext has two lists (shops and coins) and so does UnityOfWork. UnitOfWork just calls "Save" on DataContext. So it's a wrapper. It doesn't do anything. I don't see how it separates any concerns or solves any problems
@@diligencehumility6971 Yes, his implementation has no meaning at all, since he's calling Save method of the individual repositories before calling again Save in the UoW... a real UoW implementation keeps track of all changes in memory, then commits them (save) when a Save method is called, or in most cases, when the UoW is disposed like this: using (var unitOfWork = new UnitOfWork()) { // data changes here are tracked automatically, no need to call .Save on anything var player = unitOfWork.Players.GetById(123); var shop = unitOfWork.Shops.GetById(321); player.Money -= 100: shop.Money += 100; player.Items.Add("Sword"); shop.Items.Remove("Sword"); } // here data is saved without calling any Save method, since UnitOfWork is IDisposable, saving occurs in Dispose() method which is called automatically since we're using a "using" block.
@@NadjibBait I'm actually kind of confused as to how he even saves the data. His UoW has 3 properties -> dataContext, Players(which has its own dataContext) and Shops(Which also has its own dataContext). So how does calling dataContext.Save() actually make the Players and Shops save?
Nice video! So do you need the Save method or even the dataContext on the repository anymore? Once you have the UnitOfWork, it seems to become redundant right?
The advantage of the individual repository implementations is that you can implement special functions depending on the data structure you’re trying to access. For example, the Shops repository could have a unique method called “FindAllByInventoryCount(int count)” or something to that affect. (Not a great example haha)
@@NadjibBait All mothod names should be a verb, thats why I asked. So I still belive name was incorrect. If the intent was as you said I would propabbly name it 'GetDataset()'
Yes checked again, you're right, it's a method, should have been a property thought, but it's ok, since we know it's a repository then we know that Set() refers to a collection. But if it was me, I would have made it a property to avoid any confusion.
this is not important at all, just my brain not letting me move on but in the Load() of the JsonDataContext there is a FilePath that I can't seem to figure out where it comes from. how is it there? where are the red squiggly lines? D:
Parsing and writing JSON is pretty fast with the right implementation. It's definitely negligible with small data. It's more correct to say that byte arrays is more _compact_ than JSON, but it doesn't automatically make it _faster_. It depends on the implementation and the layout of your data. Another complexity that byte arrays add is that if you want to be able to change the layout, add additional data and more, you will need a way to version it in order to support backwards compatibility-which can add additional overhead to your parsing. This is relatively easy to do with JSON, as it is simply plain text and not binary. If you work with really large JSON data, there are also ways to stream JSON, e.g. by separating data by a delimiter (e.g. newline) that can parse objects individually.
So it looks like the "little bit of cleanup" at the end was the important part of this. He only calls save after all of the changes have been made. This could have been done without the unit of work. The changes are being made to the contexts in both examples. Then an async call is made to save at the end. I just don't see any point to a unit of work that does nothing but straight passthrough. I also don't see why this is a component at all. After a thorough and well-paced video explaining the problem in detail the solution was rushed to the point that the changes could hardly be seen and there was no explanation of how the solution works or solves the problems. This was so disappointing.
Love the videos, but I wish some of the shots of the code would be on the screen for longer and the edit were a little less frantic. And would love a video on data binding models like MVC and MVVM
Great content. I’m an artist who has been trying to learn to code on the side. I can’t tell you how many courses I’ve sat through where they just get you to copy what they are typing, and I’ve learned nothing.
@@InfallibleCode hey all the best for the new year and stuff, but it seems as tho u are'nt addressing the negative comments in this chat as they are very valid..the number of ppl not understanding the content is far greater than the number of ppl giving you credit..I love your content but this is pretty sad to see that you haven't even acknowledged the constructive criticisms thus far..will continue reading the comments to see if you addressed it.. reply discouraging tho..
Calling classes data structures honestly feels blasphemous. PSA that you should probably learn CS theory separately from Unity. This way you won't be mislead by confusing/incorrect jargon.
The way I understood it is that he's saving the data async. So inside his code he's performing two async writes, which might lead to data loss. Because the second save might happen while the first one hasn't finished yet. Or if you're on the web you're not guaranteed that two requests to the server from the same device will reach their destination in the same order you sent them, and the same goes for the server response back. So he basically created this unit of work abstraction, where he gathered the pending changes, so he can handle them in one go.
I really like your content , this video great Topic but you made it short and unclear ....sorry but littl bit more would made great Repo Design video ....bitter taste :/
I don't get it, I tried to write it again it disappeared again lol. Whelp. Whatever. It was about naming conventions, a suggestion. Something's up with RU-vid.
@@thedude8134 RU-vid automatically deletes comments that have censored words in them. You might be tripping it on accident, it's happened to me quite a few times despite being rather inane
@@toastyshrimp1882 I dont think i've written anything offensive or inappropriate there ... But you might be right, thanks. I've also just read that they could review comments before actually posting them, especially for a few specific countries. Censorship is real nowadays...
