Name: Flutter TDD 清潔架構課程 [2] - 實體與用例 (Flutter TDD Clean Architecture Course [2] – Entities & Use Cases)
Uploaded: 2024-06-12T18:21:11.000Z
Duration: 40 min 23 s

In the first part, you learned the core concepts of clean architecture as it pertains to Flutter.

在第一部分中，您學習了與 Flutter 相關的簡潔架構的核心概念。

We also created a bunch of empty folders, which you can see on the side right now, for presentation, domain, and data.

我們還創建了一堆空文件夾，你現在可以在邊上看到，分別用於展示、域和數據。

This is for the Number Trivia app we are building.

這是我們正在開發的數字瑣事應用程序。

And now it's time to start filling in these empty folders with actual code, of course, using test-driven development.

現在是時候開始用實際代碼填充這些空文件夾了，當然要使用測試驅動開發。

Hello, welcome to ResoCoder, where you are getting prepared for real app development by building better, faster, more stable apps.

您好，歡迎來到 ResoCoder，在這裡，您將通過構建更好、更快、更穩定的應用程序，為真正的應用程序開發做好準備。

So subscribe and hit the bell if you want to grow your coding skills.

如果你想提高編碼技能，請訂閱並按鈴。

So, of course, whenever you are building an app, you should start with the UI and user experience first, but I've done that homework for you.

當然，無論何時創建應用程序，您都應該首先從用戶界面和用戶體驗入手，但我已經為您做了這方面的功課。

As you've seen in the previous tutorial, the app looks something like this.

正如您在前面的教程中所看到的，應用程序看起來是這樣的。

The app looks like this, the actual coding process, though, will happen from the innermost stable layers and will progress toward the outer layers.

應用程序看起來是這樣的，但實際的編碼過程將從最內層的穩定層開始，然後向外層推進。

So in the case of clean architecture, as it was proposed by Uncle Bob, we can see that we should start from the domain layer, particularly from entities.

是以，就鮑勃大叔提出的 "簡潔架構 "而言，我們可以看到，我們應該從領域層入手，尤其是從實體入手。

So we are going to create an entity right now.

是以，我們現在要創建一個實體。

Before we do that, though, before we can create an entity for the number trivia, we have to add some packages over to pubspec.yaml, because we are going to be using quite a lot of packages to make things easier for us, of course.

不過，在此之前，在為數字瑣事創建實體之前，我們必須在 pubspec.yaml 中添加一些套裝軟體，因為我們將使用大量套裝軟體來簡化工作。

And with that, I have to tell you to make sure you check out the written tutorial from the link in the description, where you can find all of the code written in this video, all of the links, and all of that good stuff.

是以，我必須告訴大家，請務必通過說明中的鏈接查看書面教程，在那裡你可以找到本視頻中編寫的所有代碼、所有鏈接以及所有好東西。

And go through this lesson at your own pace.

請按照自己的節奏來學習本課。

This pubspec.yaml file is one of the few things which I'm going to just copy and paste over on video so that I don't bore you to death.

這個 pubspec.yaml 文件是我要在視頻中複製粘貼的少數幾個文件之一，這樣就不會讓你覺得無聊了。

So let's just delete all of these unnecessary comments.

所以，還是把這些不必要的評論都刪掉吧。

We'll just clutter up the pubspec.yaml file.

我們只會讓 pubspec.yaml 文件變得雜亂無章。

And then the dependencies and dev dependencies will be the following.

然後，依賴項和開發依賴項如下。

So we have getit, which is the service locator.

我們有 getit，它是服務定位器。

I've added all of the dependencies right now so that we later do not have to come back to this yaml file and just lose time on that.

我現在已經添加了所有的依賴項，這樣我們以後就不必再回到這個 yaml 文件，以免浪費時間。

Then we have flutter block for state management, equatable for value equality.

然後，我們用 flutter 塊來進行狀態管理，用 equatable 來實現值相等。

Then we are going to touch on some functional programming concepts.

然後，我們將學習一些函數式編程概念。

Then for remote API, we have connectivity and HTTP packages, of course.

當然，對於遠程 API，我們還有連接和 HTTP 包。

And for local cache, we are going to be using just simple shared preferences.

對於在地緩存，我們將使用簡單的共享首選項。

As for dev dependencies, these are the ones which do not get packaged together with your app once you build it.

至於開發依賴項，這些依賴項在您構建應用程序時不會與應用程序打包在一起。

This was here even before I think by default.

我想，這在默認情況下就已經存在了。

And then we have Mockito for creating mocks.

此外，我們還有用於創建模擬的 Mockito。

We are going to get to all of this as we progress forward with this tutorial.

隨著本教程的深入，我們將瞭解所有這些內容。

But just so that you have all of the packages already present, we've added them over here.

不過，為了讓大家能看到所有的套裝軟體，我們已經把它們添加到了這裡。

And I'm just going to delete all of the other comments so that they don't clutter up pubspec.

我將刪除所有其他評論，以免它們擾亂 Pubspec。

The pubspec.yaml file is completely finished.

So let's now move on to creating the actual entity.

現在，讓我們開始創建實際的實體。

The first question we have to ask ourselves is what kind of data will the NumberTrivia operate with?

我們要問自己的第一個問題是，NumberTrivia 將使用什麼樣的數據？

Well, of course, with NumberTrivia entities.

So we can create a new file under the domain entities.

是以，我們可以在域實體下創建一個新文件。

Let's call it NumberTrivia.dart, of course.

當然，我們就叫它 NumberTrivia.dart。

And now we have to take a look at the JSON response from the API because based on that response, we are going to model our class here.

現在，我們必須查看一下來自 API 的 JSON 響應，因為根據該響應，我們將在這裡為我們的類建模。

So if you go to numbersapi.com forward slash 42 or some other number and then question mark JSON, so it's a query parameter, you will obtain the following response.

是以，如果您訪問 numbersapi.com 的正斜槓 42 或其他數字，然後用問號標記 JSON，將其作為一個查詢參數，您將得到以下響應。

And of course, this link is also available from the written tutorial.

當然，這個鏈接也可以從書面教程中獲取。

So this is the response which we will be operating with throughout our app.

是以，這就是我們將在整個應用程序中使用的響應。

And we need to model our NumberTrivia entity so that it can contain this kind of data.

我們需要為 NumberTrivia 實體建模，使其能夠包含此類數據。

So what do we actually really need from this JSON object?

那麼，我們到底需要這個 JSON 對象做什麼呢？

Well, we need the text, obviously, because that's the core, so to say, functionality of our NumberTrivia app.

顯然，我們需要文本，因為這是我們的 NumberTrivia 應用程序的核心功能。

We are going to store the number, but then we have two interesting fields, which are found and type.

我們要存儲的是數字，但還有兩個有趣的字段，分別是 "找到 "和 "類型"。

We are not going to need those at all because found is completely irrelevant for our case, and the type will be always trivia.

我們根本不需要這些，因為 "發現 "與我們的情況完全無關，而 "類型 "永遠是瑣事。

Well, if I search for a number other than 42, so for example, some complete gibberish long number, which doesn't have any entry in the numbers API and search for that, you can see that found is false, but we still obtain some kind of a reasonable response that this is an uninteresting number.

好吧，如果我搜索一個 42 以外的數字，例如，一個完全胡言亂語的長數字，在數字應用程序接口中沒有任何條目，然後搜索這個數字，你可以看到發現是假的，但我們仍然得到了某種合理的迴應，即這是一個無趣的數字。

So we can still display even this message to the user in the app.

是以，我們仍然可以在應用程序中向用戶顯示這條資訊。

We do not need to worry at all whether or not the number was found.

我們完全不必擔心號碼是否被找到。

So the bottom line is that we need the text and number fields to map to properties in our app.

是以，我們需要將文本和數字字段映射到應用程序中的屬性。

So let's create a class, NumberTrivia, which will extend Equatable.

是以，讓我們創建一個名為 NumberTrivia 的類，它將擴展 Equatable。

This is so that value equality is made simple because by default, Dart supports only referential equality.

這樣做的目的是使值相等變得簡單，因為默認情況下，Dart 只支持引用相等。

So even two objects which contain completely the same data will not be equal unless they are referencing to the same point in memory.

是以，即使是包含完全相同數據的兩個對象也不會相等，除非它們引用的是內存中的相同點。

With Equatable, this is completely changed.

有了 Equatable，情況就完全不同了。

When two objects contain the same values, the same data, they will be equal.

當兩個對象包含相同的值、相同的數據時，它們就會相等。

And we do not need to override equal operator or hash code, anything like that.

我們不需要覆蓋等號運算符或哈希代碼之類的東西。

And now we need to store the text and number.

現在我們需要存儲文本和數字。

So final string text, and then final int number.

所以是最終字符串文本，然後是最終 int 數字。

And of course, we need to put them into constructor.

當然，我們需要將它們放入構造函數中。

So we can just hit control dot, at least in VS code, and create constructor for all of these fields here.

是以，至少在 VS 代碼中，我們可以直接點擊控制點，為所有這些字段創建構造函數。

But we are not just going to have this kind of a constructor with unnamed arguments.

但我們並不打算只使用這種帶有未命名參數的構造函數。

And of course, we are going to make them required.

當然，我們也會把它們變成必需品。

是以，我們需要導入元套裝軟體。

And we mustn't forget to pass these over to the super constructor, because Equatable needs to know which properties to make equality happen on.

我們不能忘記將這些屬性傳遞給超級構造函數，因為 Equatable 需要知道在哪些屬性上實現平等。

So we are going to pass them in as a list.

是以，我們要將它們作為一個列表傳入。

So we pass in text and also number to the super constructor, which is Equatable.

是以，我們將文本和數字傳遞給超級構造函數，也就是 Equatable。

And you may have noticed that we didn't do any test driven development here.

你可能已經注意到，我們在這裡沒有進行任何測試驅動開發。

That's because this class is really, it doesn't have any logic.

這是因為這個類實在是沒有任何邏輯可言。

There is why we aren't writing any tests for this number trivia entity.

這就是為什麼我們沒有為這個數字瑣事實體編寫任何測試的原因。

Should you have any logic inside your entity, you would write test even for entity, but that's not the case with this one.

如果您的實體內有任何邏輯，您甚至會為實體編寫測試，但這個實體並非如此。

All right, now let's talk about use cases.

好了，現在我們來談談使用案例。

They are where the business logic gets executed.

And sure, there won't be much logic in the number trivia app, because all a use case will do is to get data from a repository.

當然，數字瑣事應用程序中不會有太多邏輯，因為用例所做的只是從存儲庫中獲取數據。

So just so you can see that, here we go with the diagram.

所以，為了讓你看清楚，我們在這裡用圖表來說明。

It will get data from the repository and they will communicate together through these entities.

它將從存儲庫中獲取數據，並通過這些實體進行通信。

And we have created just one such entity called number trivia a few moments ago.

剛才我們就創建了一個這樣的實體，叫做數字瑣事。

And we are going to have two use cases in our finished app, getConcreteNumberTrivia and getRandomNumberTrivia.

在我們完成的應用程序中，將有兩個用例：getConcreteNumberTrivia 和 getRandomNumberTrivia。

By looking at this diagram, as I've already said, you know that use cases get data from repositories, and then they pass that data, which in this case are entities, over to the presentation logic holders and to the whole presentation layer.

通過觀察這個圖表，正如我已經說過的，你會知道用例從存儲庫中獲取數據，然後將這些數據（在本例中是實體）傳遞給呈現邏輯持有者和整個呈現層。

So it kind of makes sense that when a use case is communicated with repositories, the repository should return an entity, right?

是以，當用例與資源庫通信時，資源庫應該返回一個實體，這也是合情合理的，對嗎？

But because we have to allow for asynchronous operations, we are going to wrap this entity, which in this case is number trivia, into a future.

但是，由於我們必須允許異步操作，所以我們要把這個實體（在本例中是數字瑣事）包裝成一個未來。

But that's not the actual case of what we are going to do.

但這並不是我們要做的實際情況。

We have to think about error handling as well, because is it the best choice to let exceptions freely propagate?

我們還必須考慮錯誤處理，因為讓異常自由傳播是否是最好的選擇？

Having to remember, and when you have to remember something, you know that that's not cool.

必須記住，而當你必須記住一些東西時，你就會知道那並不酷。

We have to remember to cache them somewhere else in the code if we let exceptions just nicely propagate at their own peril.

如果我們任由異常自顧自地傳播，就必須記住在代碼的其他地方緩存它們。

I do not think that this is the best choice.

Instead, we want to catch exceptions as early as possible inside the repository here, and then return failure objects from the repository methods.

相反，我們希望儘早在版本庫中捕獲異常，然後從版本庫方法中返回失敗對象。

So unlike exceptions, you will not have to try and catch all of these exceptions.

是以，與異常不同，您不必嘗試捕獲所有這些異常。

You will have failure objects, which are returned as regular objects, return types from methods.

您將從方法中獲得失敗對象（作為普通對象返回）和返回類型。

字幕列表影片播放

Flutter TDD 清潔架構課程 [2] - 實體與用例 (Flutter TDD Clean Architecture Course [2] – Entities & Use Cases)

bunch

present

matter

description