Сергей Протько

зачем нужно делать свой repository на каждую сущность

Не на каждую сущность а только для сущностей, которые выступают корнями агрегатов сущностей. Ну то есть если у вас есть сущность Product и ProductImage к примеру, то репозиторий вы делаете только для продуктов.

Почему нельзя использовать шаблон Repository для работы с несколькими сущностями сразу

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

Причем полки эти могут содержать различные бизнес правила вдухе "пользователь не может положить на полку больше N продуктов пока не заплатит дополнительную деньгу".

И для каждой сущности будут свои правила как и кто может их где хранить. Банальное соблюдение принципа единой ответственности и разделения обязанностей.

но так и не понял, в чем его прелесть.

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

По сути главное что бы ваш код о контейнере ничего не знал. ЧТо бы вы в один долгий зимний вечер могли влегкую заменить все на "ручную" сборку и сам код трогать не пришлось... Ну аннотации/атрибуты это уже компромис для удобства.

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

комплектующие словом можно так же добавить как продукты в каталог. И просто делать many-to-many связь между комплектующими и системным блоком.

- Функциональное программирование - концепция не привязанная к языку
- ООП - концепция не привязанная к языку (даже если у вас чисто функциональный язык программирования вы можете "эмулировать" объекты для сокрытия состояния).
- Тестирование кода - не привязано к языку. Так же как и подходы вроде TDD и BDD (тут хорошо Кент Бэка подходит)
- DDD - не привязано к языку (читать Эрика Эванса)
- Рефакторинг (Мартин Фаулер)
- Архитектура приложений (про SOLID читаем у Роберта Мартина, про GRASP - у Крэйга Лармана. Так же есть всякие "программист-прагматик" дэйва томаса и т.д. Ну и опять же Фаулер)
- Базы данных - вообще не привязано к языку.

Можно так долго продолжать. По сути добрых 90% всего не привязано к языку.

Что такое репозиторий? Это что-то что отвечает за хранение данных. Целиком и полностью. То есть вот простенький интерфейс простенького репозитория:

interface UserRepository {
    public User getUser(UserID id);
    public void add(User user);
    public void remove(User user);
}

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

Репозиторий который умеет только выборки делать - это не репозиторий. Это штука для выборок, Finder. Так же мы должны тут заметить, что "строками таблиц" является объект типа User, а репозиторий представляет собой абстракцию от таблицы (очень упрощенно. есть еще паттерн table data gateway который отвечает именно за одну таблицу, репозиторий же может хэндлить и связи между таблицами и вообще оперирует именно объектами предметной области а не их отображением на базу).

Active Record же делает именно то, что говорит название. Это объект, который представляет собой одну строку из таблицы. Он сам может себя вставить, обновить или удалить из таблицы. Однако "найти себя" он не может к примеру, за это отвечает какой-то другой объект (мне нравится название Finder, поскольку это именно то что делает объект - ищет наши строки таблиц). Частенько для упрощения методы файдеров делаются как статические методы.

По сути ActiveRecord есть ничто иное как упрощенная комбинация из Domain Object + Row Data Gateway.

n-layered архитектура - это просто архитектура построенное на рандомном количестве слоев. оно определяет базовые принципы разделения ответственности и все такое, но на этом все.

onion - тут уже идет уточнение, что мол в самом сердце у нас core-domain, сущности, базовые бизнес правила. От него уже идет дальше domain layer, application layer и т.д. То есть сначала мы проектируем core-domain а потом уже все остальное.

Есть еще гексагональная - это опять же уточнения для n-layered архитектур, что мол каждый слой отделен друг от друга за счет dependency inversion. На границах слоев всегда есть интерфейсы, а у внешнего слоя - реализация. Потому ее называют "архитектура портов и адаптеров".

Есть EMGU, биндинг OpenCV для C#. Там же можно найти примеры трекинга объектов.

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

реддит.

Ну про angular styleguide вам уже написали. Так же добавлю что было бы неплохо почитать про SOLID принципы применительно к javascript и в принципе поучить сам javascript. Так же разберитесь наконец что такое MVC (не читайте одну статью, за 40 лет почти эти три буквы для многих стали значить слишком много разного), MVVM и т.д. Так же есть неплохой список вопросов который можно использовать как план изучения angular. Но еще больше профита даст внедрение TDD.

Раз никто не занимается менторством, то найдите себе оного. И желательно не живого, так как живые менторы склонны к субъективизму.

Идеальный ментор - юнит тесты. Причем основную ценность для вас они будут представлять когда кода который вы собираетесь тестировать вы еще не писали.

Скажем вам поставили задачу - написать какую-нибудь штуковину небольшую. Перед тем как садиться и писать, на этапе когда вы хотите обдумать как это будете делать, напишите тест. Если вам не удобно тестировать ваш код, или получается что-то странное, это будет сигналом что что-то пошло не так. Разберитесь что именно мешает. Возможно что-то можно вынести в отдельные сервис или еще что-нибудь эдакое. Возможно ваш тестируемый код берет на себя слишком многое.

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

ну и больше пробуйте, эксперементируйте. А для этого опять же нужны тесты.

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

и дальше получать некоторую частоту.

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

По поводу "как сгенерить звук" гуглите "Generate WAVE"

на будущее:

- вам нужны все возможные перестановки букв, а не все слова
- перестановки по английски будут "permutations"
- гугл

https://en.wikipedia.org/wiki/Heap%27s_algorithm

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

репозиторий не покрывается юнит тестами (иначе выйдет так что вы будете тестировать не свой репозиторий а Entity Framework) Вот и все. Используйте интеграционные/функциональные тесты.

сгенерить.

https://github.com/Codearte/jfairy