![]() ![]() In this scenario, there is no right or wrong answer, and you have to use your best judgement on a case-by-case basis.Īside from this, there is a very common mistake that we should avoid. What if it's shared among 5 features? Or 10? If your app has 20 features and has some code that needs to be shared by only two of them, should it really belong to a top-level shared folder? In these cases, it's easy to end up with folders called shared or common, or utils.īut how should these folders themselves be organized? And how do you prevent them from becoming a dumping ground for all sorts of files? What if two or more separate features need to share some widgets or model classes? Of course, when building real apps you'll find that your code doesn't always fit neatly into specific folders as you intended. However, things are not so easy in the real world. So it would appear that the feature-first approach wins hands down! □ if we want to delete a feature, there's only one folder to remove (two if we count the corresponding tests folder).whenever we want to add a new feature or modify an existing one, we can focus on just one folder.In comparison to the layer-first approach, there are some advantages: I find this approach more logical because we can easily see all the files that belong to a certain feature, grouped by layer. ‣ lib ‣ src ‣ features ‣ feature1 ‣ presentation ‣ application ‣ domain ‣ data ‣ feature2 ‣ presentation ‣ application ‣ domain ‣ data Using the same example as above, we would organize our project like this: And inside that folder, we can add the layers themselves as sub-folders. The feature-first approach demands that we create a new folder for every new feature that we add to our app. And this makes it harder to work on individual features because we have to keep jumping to different parts of the project.Īnd if we decide that we want to delete a feature, it's far too easy to forget certain files, because they are all organized by layer.įor these reasons, the feature-first approach is often a better choice when building medium/large apps. This approach is easy to use in practice, but doesn't scale very well as the app grows.įor any given feature, files that belong to different layers are far away from each other. ![]() ‣ lib ‣ src ‣ presentation ‣ feature1 ‣ feature2 ‣ feature3 <- ‣ application ‣ feature1 ‣ feature2 ‣ feature3 <- only create this when needed ‣ domain ‣ feature1 ‣ feature2 ‣ feature3 <- ‣ data ‣ feature1 ‣ feature2 ‣ feature3 <- Layer-first: Drawbacks If we adopt the layer-first approach, our project structure may look like this: To keep things simple, suppose we have only two features in the app. So let's explore these two conventions in more detail and learn about their tradeoffs. In practice, a feature-first or layer-first approach is often used. □īut as soon as we start adding more pages and have various data models to deal with, how can we organize all our files in a consistent way? Of course, if we're building just a single-page app, we can put all files in one folder and call it a day. data: repositories, data sources, and DTOs (data transfer objects). ![]() presentation: widgets, states, and controllers.This architecture is made of four distinct layers, each containing the components that our app needs: So for the rest of this article, we'll use my Riverpod App Architecture as a reference: Flutter App Architecture using data, domain, application, and presentation layers. ![]() And those layers will show up somewhere as folders in our project. This is because app architecture forces us to define separate layers with clear boundaries. In practice, we can only choose a project structure once we have decided what app architecture to use. Project Structure in Relation to App Architecture A fully managed API for developers that enables you to generate beautiful PDF or screenshots and store them directly in your own S3 bucket without compromising privacy. Help me keep it that way by checking out this sponsor: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |