ASP.NET + C # Мультипроектное решение. Где я должен поставить свои глобальные функции полезности?

Question

Как сказано в названии, у меня есть мультипроектное решение.

У меня есть «основной» проект, который загружен большинством других проектов.

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

(в Project_B, который зависит от ядра)

string str = FormatPhoneNumber(inputString);

В худшем случае, я думаю, я мог бы жить с каким-то определителем:

string str = util.FormatPhoneNumber(inputString);

Answer 1

Лучший способ сделать это - создать проект dll (может быть, называемый что-то вроде "CommonCode"?), Чтобы затем вы могли ссылаться на этот dll из всех ваших других проектов и получать к ним доступ к классам и методам.

Вам понадобится где-то какой-то «классификатор» (как вы его называете), но для уменьшения воздействия используйте оператор using в верхней части каждого файла, например,

using util;

Answer 2

Используйте метод расширения, чтобы было проще вызывать метод без использования имени класса.

public static class Util {
    public static string FormatPhoneNumber(this string input) {
        :
    }
}

Метод теперь будет отображаться на каждом строковом объекте. Вам не нужно знать, из какого класса это происходит. Однако, если класс расширения объявлен в другом пространстве имен, вы все равно должны импортировать пространство имен.

string formattedString =  inputString.FormatPhoneNumber();

Answer 3

Попробуйте создать свою собственную библиотеку утилит.
Создайте проект библиотеки классов и поместите туда свои классы утилит

Я сам пытаюсь придерживаться соглашения об именах, например [companyName] .Util. [Subdomain] Ваш пример, вероятно, поместился бы в моем [CompanyName] .Utils.StringHelpers

Затем вы должны создать статический класс StringHelper со статическим методом FormatPhoneNumber. Вы увидите, что эти личные библиотеки быстро растут. Группируя их, вам не нужно загружать весь ваш код, если вам нужен только набор функций.

Answer 4

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

С классификатором не должно быть никаких проблем. Я предлагаю не помещать несвязанную функцию в класс Utils, а использовать, например, Formatting класс для всех функций форматирования. С другой стороны, как предположил s_ruchit, методы расширения (например, для строкового класса) также могут пригодиться.

(Я упоминал, что этот редактор §% $ & MarkDown не позволяет вводить символ [at] на немецкой раскладке клавиатуры, потому что вместо этого он создает цитату? Вздох.)

Answer 5

Если вы хотите, чтобы весь код имел доступ к этим методам, тогда используйте методы расширения, в противном случае я бы использовал класс Util в сборке ядра.

FWIW, если вы следуете за более формализованным пространством имен в качестве подсказок Бориса (рекомендуется избегать конфликтов), вы можете сокращать его с помощью ключевого слова using:

using Util = [CompanyName].Utils.StringHelpers;

Я склонен следовать принципу DRY и создавать псевдоним, как только он мне понадобится более одного раза.

Answer 6

Если реализуемая функция может использоваться только в контексте вашего приложения, я бы порекомендовал вам поместить ее в сборку Core (в отдельном пространстве имен, например, "Utils") или в новую библиотеку DLL вашего приложения. решение. Только если функция может использоваться в нескольких проектах, имеет смысл создать служебную библиотеку. Но всегда имейте в виду, что служебная библиотека имеет смысл, только если она поддерживается регулярно.

Answer 7

Вам нужно поместить функции в статические классы. Вы не можете избежать квалификации (в C # нет глобальных функций):

<%= Formatters.PhoneNumber(rawData) %>

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

Сборка, к которой принадлежит каждая, должна быть очевидной: функции форматирования, используемые только на уровне представления (сам проект ASP.NET), принадлежат к ней. Действительно общие функции могут войти в ядро.

Answer 8

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

public class Utility
{
  public static string FormatPhoneNumber(string input)
  {
    ...
  }
}

// usage:
string output = Utility.FormatPhoneNumber(input);

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

Answer 9

Если вы используете C # 3.0, вы можете связать их все в один статический класс, используя их как Методы расширения .