Как абстрагироваться от различных реализаций библиотеки JSON

#c# #.net #json

#c# #.net #json

Вопрос:

Для моего проекта .NET / C # мне нужно использовать библиотеку JSON, но я должен зависеть от конкретной реализации. Я знаю, что существует множество библиотек JSON * c # *, таких как Json.NET , FastJson, Simple Json (simplejson.codeplex.com ) и т.д. Теперь, как мне абстрагироваться от различных реализаций, чтобы я мог переключать библиотеки в будущем. У меня нет контроля над другими библиотеками, но у меня есть полный контроль над своим проектом. Ищу ваши мнения.

Ответ №1:

В зависимости от ваших потребностей вы можете создать единую точку входа в любую библиотеку, которую вы хотите использовать.

 public static class Json
{
    public static string Serialize(object o)
    {
        // ...  
    }

    public static T Deserialize<T>(string s)
    {
        // ...
    }
}
  

Комментарии:

1. Что ж, тогда я буду создавать отдельные классы, содержащие необходимые функции, для каждой библиотеки, верно?

2. @Mercurial1278 — Ну, это действительно зависит. Вы действительно рассчитываете менять библиотеки каждую неделю или вы просто хотите сделать такой переход умеренной задачей?

3. Я хочу использовать Json. СЕЙЧАС все предлагают NET, но я знаю, что проекты с открытым исходным кодом время от времени забрасываются, так что через год я могу измениться.

4. Я согласен, что это лучшее решение, если вы просто хотите быть в безопасности «на случай», если вы решите переключиться на другую библиотеку. Если вы хотите иметь возможность менять местами ту или иную библиотеку JSON без перекомпиляции или параллельного тестирования, предложенное мной решение может это сделать.

5. Спасибо вам за помощь, ребята. Решение ChaosPandion на данный момент подходит мне лучше всего.

Ответ №2:

Одним из способов сделать это было бы создать интерфейс, который все библиотеки могут сопоставлять, затем реализовать класс-оболочку для каждой, который реализует интерфейс с использованием этой конкретной библиотеки. Каждый класс-оболочка должен находиться в отдельной сборке, чтобы избежать зависимости от библиотеки класса-оболочки.

Затем, когда вы выберете реализацию во время выполнения, вы сделаете это путем создания экземпляра класса-оболочки посредством отражения.

Комментарии:

1. Очень похоже на подключаемую архитектуру C #, идея понравилась.

2. Хотя это хорошее решение, я бы предложил сначала заняться чем-то более простым.

Ответ №3:

Лучший способ — создать интерфейс.

Вот как мы делаем это в Facebook C # SDK (http://facebooksdk.codeplex.com )

 public interface IJsonSerializer
{
    string SerializeObject(object obj);
    object DeserializeObject(string json, Type type);
    T DeserializeObject<T>(string json);
    object DeserializeObject(string json);
}
  

Комментарии:

1. Поскольку вы не можете убедиться, что другие библиотеки реализуют ваш интерфейс, создаете ли вы один класс для каждой отдельной библиотеки, реализующей этот интерфейс?

2. да, нам приходится вручную создавать интерфейс для каждой библиотеки. вот пример того, как мы поступаем с SimpleJson facebooksdk.codeplex.com/SourceControl/changeset/view /…