2016-07-25 7 views
3

Для доступа к Ключам приложений в библиотеке классов нам нужно сделать следующий код в каждой библиотеке классов и классе, где нам нужно получить доступ к AppKey?Доступ к данным ключа приложения из библиотек классов в .NET Core/ASP.NET Core

public static IConfigurationRoot Configuration = new ConfigurationBuilder().AddJsonFile("appsettings.json").Build(); 

Это то, что я нашел в Microsoft docs, но это выглядит очень избыточна.

класс запуска в проекте, как показано ниже

public class Startup 
    { 
     public IConfigurationRoot Configuration { get; set; } 

     public Startup() 
     { 
      var builder = new ConfigurationBuilder() 
       .AddJsonFile("appsettings.json"); 

      Configuration = builder.Build(); 
     } 

     public void ConfigureServices(IServiceCollection services) 
     { 
      services.AddEntityFramework().AddEntityFrameworkSqlServer() 
       .AddDbContext<DbContext>(options => 
        options.UseSqlServer(Configuration["Data:MyDb:ConnectionString"])); 
     } 
    } 

Тогда как я должен вводить этот «IConfigurationRoot» в каждом классе проекта. И нужно ли повторять этот класс Startup в каждой библиотеке классов? Почему это не является частью .NET Core Framework?

+1

Чувак! кто-то должен быть действительно сумасшедшим, чтобы проголосовать за вопрос, даже будучи квалифицированным, чтобы иметь учетную запись в SO, Кто когда-либо проголосовал за этот вопрос, если вы не знаете .NET, найдите репетитора, который научит вас .NET через 30 дней, просто не раздражайте меня. И эта БД даже не имеет качества комментирования, почему он/она выполняет этот акт BS. Это очень раздражает. Команда SO должна действительно что-то делать в таких действиях. – HaBo

ответ

1

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

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

+0

Если я получу вас правильно, вы говорите, что я не должен пытаться обращаться к AppKeys из любых библиотек классов, а должен передавать значения как Params из моего основного проекта (например, веб-сайта)? – HaBo

+0

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

+0

Одним из способов, которым это может помочь, является создание более общих библиотек классов, которые будут работать с приложениями Web Forms, приложениями MVC, приложениями Windows Forms и/или консольными приложениями. Большинство библиотек не заботятся о том, где они находятся, и не должны иметь дело с тем, что информация о конфигурации может храниться в разных местах для разных приложений. –

6

Рекомендованным способом является использование options pattern, предоставляемого Microsoft и используемого в основном в ASP.NET Core.

В основном вы создаете сильный типизированный класс и настраиваете его в классе Startup.cs.

public class MySettings 
{ 
    public string Value1 { get; set; } 
    public string Value2 { get; set; } 
} 

и инициализировать его в классе Startup.

// load it directly from the appsettings.json "mysettings" section 
services.Configure<MySettings>(Configuration.GetSection("mysettings")); 

// do it manually 
services.Configure<MySettings>(new MySettings 
{ 
    Value1 = "Some Value", 
    Value2 = Configuration["somevalue:from:appsettings"] 
}); 

затем вводите эти параметры везде, где это необходимо.

public class MyService : IMyService 
{ 
    private readonly MySettings settings; 

    public MyService(IOptions<MySettings> mysettings) 
    { 
     this.settings = mySettings.Value; 
    } 
} 
+0

Это ничего, кроме повторения этого кода в каждом классе, мне нужно получить доступ к mySettings? разве это не избыточная работа? – HaBo

+0

Нет, у вас есть только ** один ** Класс Startup.cs: в вашем веб-приложении и нигде больше! В библиотеках классов и всех других сервисах вы вводите в класс 'IOptions mysettings'. И нет, это не избыточно, потому что вы только читаете/инстанцируете его один раз и передаете его повсюду (вы разрешаете новый встроенный контейнер для инъекций Dependency Injection Container). Библиотеки классов должны ** никогда ** иметь 'Startup.cs' – Tseng

+0

Это единственный способ работы .NET Core? Вводя IOptions в каждом классе, где мне нужно получить доступ к настройке? – HaBo

Смежные вопросы