C# Static Method vs Object Instance

Question

В настоящее время я разрабатываю веб-приложение C# MVC REST и пытаюсь выбрать одну из двух возможностей для нашего дизайна.

Не углубляясь в наш дизайн, мы намерены иметь класс для доступа к данным, который мы назовем DataSource. Каждому DataSource необходимо будет выполнить небольшие, содержащиеся блоки логики, чтобы правильно построить соответствующий ответ. Из-за желания иметь возможность использовать код горячей загрузки в будущем, мы не хотим, чтобы они были функциями на DataSource, вместо этого мы хотели бы, чтобы они были предоставлены другими сборками. У нас есть доказательство того, что это реализовано, и до сих пор такое хорошее.

Что я пытаюсь решить между написанием статического класса с помощью одной статической функции ExecuteQuery или написанием фабричного метода для создания экземпляров этих классов, которые имеют метод экземпляра, называемый ExecuteQuery.

Каковы соображения производительности между созданием нескольких короткоживущих объектов для каждого запроса, а также вызовом статических методов?

Интуитивно, статические методы будут быстрее, но я уже ожидаю, что у меня начнется головная боль, называя их отражением (для поддержки требования к горячим загрузкам).

Если для короткоживущих объектов нет огромного штрафа, они могут выиграть только на простоте.

Соответствующая информация о наших ожидают нагрузок:

• Время отклика в 300 мс - диапазон 800ms
• Средняя нагрузка около 2000 веб-клиентов
• Пик нагрузки около 4000 клиентов
• Клиенты делают запросы каждые 2 - 5 секунд
• Пиковая скорость клиента 1 запрос каждую секунду

Кроме того, каждый DataSource создаст максимум 8, в среднем 3 из этих экземпляров.

Answer 1

Использовать статический класс, который делегирует вызовы классам реализации.

Эти классы реализации должны реализовывать общий интерфейс, который позволит вам называть методы на них без необходимости отражения. И, конечно же, статические методы не могут реализовывать методы интерфейса. Реализации интерфейса должны быть экземплярами, вам нужна какая-то фабрика для их создания. Если они живут во внешних сборках, я настоятельно рекомендую вам взглянуть на Managed Extensibility Framework (MEF), см. http://msdn.microsoft.com/en-us/library/dd460648.aspx.

Каковы соображения производительности между созданием нескольких коротких объектов в каждом запросе, а также вызовом статических методов? Учитывая, что эти методы будут обеспечивать доступ к данным, последствия производительности полностью и совершенно небрежны.

Если вы используете MEF, фреймворк создаст вам одноэлементные экземпляры.

Если вы производите свою роль и хотите удалить необходимость создания этих объектов несколько раз, вы можете реализовать шаблон Singleton на них.

Answer 2

Главное решение должно быть «имеет ли этот объект состояние?»

Если «Нет», то непременно сделайте его статическим методом.

ИМХО .. PSM

Answer 3

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

• Поскольку у вас, похоже, не так много клиентов одновременно, так что это также сидит будет с шаблоном Singleton.
• Не много параллельных запросов (в основном из-за вышеприведенного заявления).
• У вас есть Определенная спецификация времени отклика.

Единственный аргумент, который я могу сделать для шаблона Factory, - это «простота». Если проект действительно чувствителен к времени, то, я думаю, у вас нет выбора. Но если вы действительно хотите производительности, пойдите с Singleton.

Answer 4

Использование MEF. Не нужно изобретать собственную инфраструктуру плагина. Он будет направлять вас к методам экземпляров, открываемым через интерфейсы. Нередко создавать объекты для запроса ... структура MVC делает это повсюду. Примеры экземпляров для каждого запроса особенно полезны для сценариев доступа к данным, так что вы можете поддерживать такие вещи, как транзакции/откаты, таким образом, чтобы опыт одного пользователя не влиял на других пользователей, пока вы явно не сделаете это. Используйте кеширование ответа, если это необходимо, если проблема с перфомансом.