Контакты

Наибольший вклад в теги

Все теги (11)

Лучшие ответы пользователя

Все ответы (15)
  • В чем отличие type и interface. В каких случаях что использовать?

    @maltsever
    Привет! Грубо говоря, интерфейс лишь описывает функциональность. А класс, который реализует этот интерфейс, должен конкретно функциональность определить. Например:
    interface IVegetable {
        name: string;
        getCalories(): number;
    }

    А конкретный класс:
    class Tomato implements IVegetable {
        name: string = 'Tomato';
        getCalories() {
           return 18;
        }
    }

    Type - это лишь типизация какой-то переменной, как правило, нестандартной, Например, мы хотим определить тип, который будет описывать степень готовности стейков:
    type SteakRoast = 'medium' | 'rare' | 'welldone';
    Таким образом, мы можем присвоить переменной типа SteakRoast только эти предопределённые значения, а иначе Typescript заорёт из-за несоответствия типа.
    Ответ написан
    3 комментария
  • К какому слою относится Repository и как возвращать Business object?

    @maltsever
    Привет! Многое зависит от деталей и количества абстракций. Попытаюсь ответить как это должно выглядеть в самом общем случае. UserRepository использует напрямую доступ к базе данных (это может быть raw sql, какая-то ORM, неважно). Поэтому логично, чтобы он находился в Data Access Layer. Он поэтому так и называется, потому что на практике их может быть несколько: SqlDataAccessLayer, MongoDbDataAccessLayer и т.д. Также если мы говорим про ООП, то интерфейс IUserRepository должен хранится именно там, где планируется его использование. В нашем случае это BLL, он же Domain Layer. Не всегда удаётся придерживаться этого правила с интерфейсом, но к этому нужно стремиться.
    По поводу того, что должен возвращать UserRepository: на самом деле без разницы. Смотря от ситуации мы можем либо возвращать просто контейнер c необходимыми данными (DTO), либо полноценного User'a. Если говорить о зависимостях, то главное понимать, что в общем случае наш Domain Layer не должен иметь зависимостей от каких-то других слоёв. А вот остальные части нашего проекта (например, DAL) могут использовать Domain Layer.
    Ответ написан
    2 комментария
  • Как научиться читать документацию правильно при слабом навыке концентрации внимания?

    @maltsever
    Привет! Хочу поделиться несколькими фишками, которыми сам пользуюсь постоянно. Во-первых, читать надо не на скорость и объем, а на понимание, читайте по часу в день, но вдумчиво. Во-вторых, перед началом изучения чего-либо обязательно ознакомьтесь с содержанием. Таким образом, читая определенную главу у Вас уже в фоне будет понимание того, что в конце этой главы Вы должны усвоить и как эта глава связана с контекстом всей книги. В-третьих, после каждого чтения или же после поступления новых знаний - вкратце записывайте их своими словами, чтобы через неделю, год Вы смогли взглянуть и освежить память. Много писать не надо, чисто тезисно.
    P.S. Если есть время, то советую посмотреть курс на английском или прочитать книгу на русском от того же автора.
    Ответ написан
    Комментировать
  • Какие есть технологии, методики или инструменты для упрощения валидации и обработки данных на Front-end и Back-end?

    @maltsever
    Поскольку мы в разделе ASP.NET, то буду говорить про него. Не знаю каким образом мы можем синхронизировать валидацию на фронтенде и бекенде, мне даже кажется это технически нереализуемо, но могу ошибаться. Если мы говорим о валидации в целом, то мы в первую очередь должны обеспечивать 100% валидацию на стороне сервера, потому что не хотим, чтобы была нарушена целостность данных и т.д. Тут надо руководствоваться принципом fail fast - как можно быстрее проверяем валидность данных из запроса. Чтобы привести валидацию к какому-то организованному виду можно использовать, например, библиотеку FluentValidation.
    Ответ написан
    1 комментарий
  • Что значит сокрытие?

    @maltsever
    Сокрытие информации очень часто называют инкапсуляцией, но это не совсем корректно. Сокрытие информации - это своего рода ограничение доступа к таким полям/методам/т.д., которые можно менять только внутри модуля. Типичный пример: объявление private переменных.
    Инкапсуляция - это сокрытие деталей реализации. Мне нравится следующий пример инкапсуляции из реальной жизни. У нас есть объект - наручные часы, этот объект реализует интерфейс IGetTime. Мы просто смотрим на часы и получаем время. При этом нам совсем не интересно каким образом это время было рассчитано внутри часов, какие инструменты при этом использовались, механические часы или цифровые - это всё не важно. Важно, что мы узнали время, а всё остальное - детали реализации, которые скрыты от нас. Аналогично и в ООП.
    Таким образом, сокрытие информации является лишь частью инкапсуляции.
    Ответ написан
    Комментировать