Если я не понял плохо, то, что вы пытаетесь достичь, это отделить ваш класс ModelInfo от выбранного вами подхода сериализации / десериализации (будь то json, плоские буферы и c), верно?
Если это так, то ваше предложение об условном импорте не будет работать (и, если это произойдет, я думаю, что это не будет хорошим вариантом, если речь идет о его обслуживании, тестировании или масштабировании.
My Было бы предложено следовать какому-либо шаблону репозитория самым простым из возможных способов. Это позволило бы вам действительно отделить способ получения ваших данных от потребителя, что позволило бы вам выбрать стратегию сериализации / десериализации или даже иметь несколько сериализаторов и т. д. c. Этот подход также очень упрощает добавление персистентности / кэша в ваше приложение в будущем, если вам это нужно.
Давайте представим простой сценарий, в котором вы хотите получить список объектов ModelInfo для использовать ваш бизнес-уровень (View Models, blocs et c), а затем ваш пользовательский интерфейс .
Давайте начнем с предположения, что у нас есть класс ModelInfo, который является целевым (тот, который мы хотим отправить на верхние уровни нашего приложения из уровня служб).
class ModelInfo {
// This is the model we want to expose to our upper layers (View Models, Blocs etc)
}
1) Сначала мы создадим интерфейс для определения контракта, который будет реализовывать каждый ApiDataManager. В Dart мы используем абстрактные классы для этого:
abstract class ApiDataManager {
List<ModelInfo> fetchItems();
}
2 - Теперь мы можем создать столько менеджеров данных Api, сколько захотим (json, flatbuffers et c), если они соответствуют ApiDataManager. На этих менеджерах мы можем импортировать необходимые библиотеки и делать соответствующие вызовы API, parsing et c. Пока у нас есть метод fetchItems(), который возвращает List<ModelInfo>, у нас все в порядке.
class jsonApi implements ApiDataManager {
List<ModelInfo> fetchItems() {
/* Here you implement a fetchItem method that parses your json server response
* and returns an ItemModel list */
}
}
class flatBuffersApi implements ApiDataManager {
List<ModelInfo> fetchItems() {
/* Here you implement a fetchItem method that parses your flatbuffers server response
* and returns an ItemModel list */
}
}
3 - Теперь мы создадим репозиторий, в который мы добавим удаленного поставщика данных API, который вы хотите использовать ( json, плоские буферы). Этот репозиторий будет использоваться нашими моделями представления, Blocs et c, для извлечения данных и получения полностью законченных объектов модели.
class Repository {
final ApiDataManager remoteDataManager;
Repository(this.remoteDataManager);
List<ModelInfo> fetchItems() {
// Call remoteDataManager.fetchItems()
// Depending on the remote data manager you have injected you'll be
// using json endpoints or flatbuffers, or whatever you want!
// Return the list to your view models, Blocs etc
return remoteDataManager.fetchItems();
}
}
4 - И, наконец, мы можем использовать наш репозиторий из нашего бизнеса или слой представления (наш виджет) и получите наш список объектов ModelInfo. На самом деле мы можем динамически внедрить тип Api, который нам нужен во время выполнения, в зависимости от логики c, которую вы хотите использовать. Вы бы использовали логи c, как это в вашей ViewModel, blo c или Widget:
// Imagine this is inside your Widget or View Model or bloc
bool isProd = false; // Whatever you want to use to control the logic
var myJsonApi = JsonApi();
var myFlatBuffersApi = FlatBuffersApi();
var apiToUse = isProd ? JsonApi() : FlatBuffersApi();
Repository myRepository = Repository(apiToUse);
// Here you have your fresh list of items!
List<ModelInfo> myItems = myRepository.fetchItems();
Надеюсь, это поможет!