Валерий Абакумов

Redux-saga — это альтернативный подход к организации сайд-эффектов. Вместо того, чтобы диспатчить функции, которые обрабатываются redux-thunk-ом, вы создаёте сагу, которая собирает всю логику обработки внутрь себя. В отличие от thunk-ов, которые выполняются, когда вы их диспатчите, саги запускаются при старте приложения и как бы «работают в фоне». Саги слушают все экшены, которые диспатчит стор, и решают, что делать с ними.

И у саг в редаксе два преимущества по сравнению с thunk-ами:
— Они позволяют организовывать сложные последовательности сайд-эффектов
— И они очень легко тестируются

1) https://habrahabr.ru/post/321050/
2) https://habrahabr.ru/post/276593/
3) Посмотреть примеры кода на https://code.msdn.microsoft.com/
- Unit of Work & Repositories Framework
- KiksApp Enterprise application architecture Onion
4) Pluralsight
- Become a Full-stack .NET Developer - Advanced Topics
- Become a Full-stack .NET Developer - Architecture and Testing
- Become a Full-stack .NET Developer - Fundamentals

тыц

Есть книга - "Оптимизация приложений на платформе .NET с использованием языка C#".
Просто сделать быстрее чем вы уже делаете без знания подробностей сложно.

У вас перепутана последовательность картиночек: Layout зовет экшн Auth-контроллера, а тот, в свою очередь, вызывает GetUser-вьюху и вставляет ее на место вызова в Layout (1 - 3 - 2)

Тем не менее, ViewBag- это индивидуальное свойство каждого контроллера (BaseController). То есть они разные для Auth-контроллера и того, который зовет Layout (назовем его X) и ваша задумка не прокатит.

Вы пытаетесь бизнес-логику вытащить на вьюхи.
Это нужно получать не с помощью отдельного экшна и вьюхи Auth-контроллера, а от сервиса (в который обернуть работу с базой). Затем протягивать этого через вью-модель экшна X-контроллера.

Ахтунг, товарищ. Перед тем как сомневаться в профессионализме своих коллег очень советую хотя бы немного сомневаться в собственном. Это как минимум изредка полезно. А теперь ноги в руки и вперёд читать про таблицы, виртуальность и методы. Это не просто полезно, но архиважно. Учитывая, собственно, вопрос.

А вопрос состоял в следующем. Вот у нас есть объекты, друг от друга наследуются, имплементируются и всё круто-прекрасно, но блджад. Зачем они нужны-то? Нет, не агрегация данных, хотя и она тоже. Нет, не агрегация реализации, хотя и она тоже. И нет, нет, не просто потому что. Хотя и это тоже... А вот подумай о такой ситуации. Есть библиотека. Да не важно какая, ну пусть это будет UI/UX. Вот есть абстрактный (!) класс кнопка. Почему абстрактный? Да потому что любая кнопка - это кнопка. Это как бы класс над классом. Кнопка может быть красной, может быть кликабельной, может становится не кликабельной после нажатия, может открывать диалог выбора файлов, а может закрывать приложение к чертям. В общем, много чего может уметь делать кнопка. И вот эту кнопку хочется поставить на формочку. И сделал создатель библиотеки такой прекрасный метод у формы PutAnyButtonHere(Button btn, Point xy). Но... Чёрт, чувак, мы должны передать объект класса Button, а у нас какой-нибудь наследник MyBestButton : BestAbstractLibraryButton, который наследник той самой Button. И у Button декларирован такой прекрасный метод TimeWhenUserClickOnMe(Point xy, AnotherInfo somethinElse), собственно... Получается, что где-то в недрах той самой библиотеки, когда автор прекрасной UI/UX библиотеки вызывает этот самый метод он должен вызвать НАШУ реализацию, а не реализацию BestAbstractLibraryButton. И уж точно не несуществующую реализацию Button (ибо метод там чисто-виртуальный). Идея виртуальных методов изначально именно в том, что есть особая таблица, которая хранит реализации отдельно, объекты отдельно, но когда мы пытаемся вызывать у объекта виртуальный метод происходит такая магия, которую принято называть поздним связыванием.

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

Сухой остаток. Если мы вызываем виртуальный метод у объекта класса наследника некоторого супер-класса имея ссылку типа супер-класса, то вызывается реализация метода наследника. Если мы вызываем не виртуальный метод у объекта класса наследника некоторого супер-класса имея ссылку типа супер-класса, то вызывается реализация метода супер-класса. В остальном поведение тривиальное.

Отсебятина. Не понимая данных вещей невозможно говорить, что принципы объектно-ориентированного программирования были усвоены. Советую прочитать "Философия Java" (вообще там Java скорее как язык для примеров, в общем-то ООП оно и в Африке ООП). Ну и пытаться разобраться в точке зрения любого человека, особенно если его компетенция хоть чем-то подтверждена (например, успешным трудоустройством).

Как офомрить долю в стартапе?

Оформление вас, как одного из учредителей юридического лица. Если организация только создается, то вносите деньгами/имуществом долю в уставный капитал огранизации. Минимально разрешенный законом уставный капитал ООО должен быть не менее 10 тыс. руб., т.е. вы вполне можете самостоятельно внести свою долю. Нет смысла раздувать уставный капитал, если организация не планирует привлекать кредиторов. Если же организация уже зарегистирована, тогда нужно нотариально оформить продажу доли и уведомить регистрирующий орган о изменении состава учредителей.

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

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

ну и правильно разделить доли изначально в соответствии с тем кто что делает (в дальнейшем при изменениях команды или ролей можно пересчитывать).

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

в общем 7 раз отмерь - и один подпиши.

Ну что значит "переходить". Стоит ли разбираться, конечно стоит, за ним будущее (возможно). Стоит ли переводить текущие проекты? А зачем? Стоит ли начинать новые, вот тут вопрос. Я думаю, что не стоит, еще довольно сыро для серьёзного продакшена. А для мелких попроктов вполне даже сойдет

В ASP .Net Contrib есть провайдеры для большинства сайтов, в том числе и для ВК

Самый простой пример, который приходит на ум: представьте, что вы хотите получать оповещения об ошибках на сайте по email/смс/чему-нибудь ещё.

С интерфейсами ваше решение будет выглядеть как-то так:

// Собственно, сам интерфейс оповещений
public interface INotification
{
    void Notify(string text);
}

public class EmailNotification : INotification
{
    public void Notify(string text)
    {
		// код по отправке почты
    }
}

public class SmsNotification : INotification
{
    public void Notify(string text)
    {
		// код по отправке смс
    }
}

// ... Еще какие-нибудь классы оповещений


// В каком-нибудь классе, где может появиться ошибка
public class MaybeErrorClass
{
    private INotification _notification;

    public MaybeErrorClass(INotification notification)
    {
		// Класс не должен знать, по какому каналу оповещать об ошибках.
		// Он работает с абстракцией
        this._notification = notification;
    }

	// Очень простой пример метода, в котором ожидаем генерацию ошибки
	public void DoSomething()
	{
		try {
			// какой-то блок, в котором можем получить ошибку
		}
		catch (Exception e)
		{
			this._notification.Notify("А у нас тут ошибка!");
		}
	}
}

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

var maybeErrorEmail = new MaybeErrorClass(new EmailNotification());
var maybeErrorSms = new MaybeErrorClass(new SmsNotification());

Теперь вопрос на засыпку: как бы вы решили подобную задачу без интерфейсов?

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

Ещё как вариант - это особый класс возврата, а-ля ASP.NET MVC ActionResut.

Т.е. все методы возвращают некоторый класс Result:

class Result<T> {
   public T Result {get; private set; }}
   public bool Success {get; private set; }}
   public IEnumerable<Exception> Errors { get ... }
   public string ErrorMessage {get ... } // этого можно и не делать

   private Result() {}
   public static Result<T> Success(T result) { return new Result() { Result = result, Success = true }; }
   public static Result<T> Fail(Exception ex) { return new Result() { Success = false, Errors = new List<Exception>() { ex }, ErrorMessage = ex.Message }; }
}

Если уж нугетом не может воспользоваться, то он точно не VS c# программист.

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