Pull to refresh
4

Жсоноукладчик третьего разряда

Send message

Если ходить во время встреч то работать вполне возможно

Ну тут классическая анекдотичная ситуация "И вы говорите"
Я скорее о том что столько читать и понимать в день очень сложно. А еще у него встречи наверное были и другие дела и он не чиллил с книжкой весь день на диване. Википедия того же мнения
https://ru.wikipedia.org/wiki/Круг_чтения_Сталина#Режим_чтения

Причем забавно что автор с одной стороны смеётся над адептами заряженный воды а с другой свято верит что Сталин читал по 300-500 страниц в день (ещё и не художественной литературы)

В опере мобильной прекрасно всё работает. Ещё и блокировка рекламы есть

Ошибка на миллион долларов

В данном случае репликой называют экземпляр приложения, например запущенный на другом компьютере

Можно сначала скомпилировать быстро а потом при необходимости в фоне перекомпилировать уже с оптимизациями.
https://github.com/dotnet/runtime/blob/master/docs/design/features/tiered-compilation.md

Статью кроме рекламы можно под спойлер убрать

У вас уже есть в статье вариант как хранить секреты на dev машине.


.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

Можно добавить в gitignore файл appsettings.Development.json и в нем хранить настройки и секреты

— Asynchronous injection
Проблема не решилась. Бизнес правило приходит снаружи конструктора/фабричного метода. Я как нехороший программист обязательно положу в туда бяку.

— Internal for infra
В одной сборке с бизнес логикой будет валяться инфра код. Не чисто.
Бизнес-логике не место в бд так как SQL для неё не предназначен
Если ты хочешь все запараллелить чтобы ускориться, то обломись

А вот и не обломись:
public async Task<List<Blog>> GetBlogsAsync()
{
    using (var context = new BloggingContext())
    using (var context2 = new BloggingContext())
    {
         // parallel queries
    }
}
Ну можно сделать memento и маппить на EF классы и обратно например. Или использовать backing fields, owned entites, value conversion.

На сколько помню ничего не заменяется. Просто добавляется. Например в случае массива в appsettings.json и appsettings.Development.json

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

Это не всегда так. Для массивов будет просто добавление элемента в массив.
Ну так это просто Property/Method Injection, а не декоратор.
Пример декоратора:
public class LoggingLayer : ILayer
{
	private readonly ILogger _logger;

	private readonly ILayer _decorated;

	public LoggingLayer(ILayer decorated, ILogger logger)
	{
		_decorated = decorated;
		_logger = logger;
	}

	public void Write(string text)
	{
		_logger.Log(text);
		_decorated.Write(text);
	}
}
Фактически мы реализовали паттерн «Декоратор».

Декоратор вроде должен реализовать тот же интерфейс что и декорируемый.
А если для инициализации агрегата потребуется over 20 параметров. Делать конструктор с кучей параметров?
И что делать если логика должна предполагать как полную так и частичную инициализацию агрегата?

Information

Rating
6,650-th
Works in
Registered
Activity

Specialization

Backend Developer
Lead