"странно, странно... не знать как посчитать резисторы это абсолютный 0 по схемотехнике. Как же это было сдано?=)"
А я и не говорил, что я не могу рассчитать резистор. Мне кажется посчитать для одного конкретного случая и посчитать параметры для всей схемы это совсем разные работы. Говорю же, схемотехника была в Proteus и на стендах, где уже все готово.
За остальное, спасибо. посмотрю приведенные ресурсы.
P.S.: Ардуино скорее как крайний вариант. Вообще хотел на PIC контроллерах что-то делать, но вроде информации больше по AVR
Юрий: Спасибо, в таком случае когда разберусь хотя бы немного со схемотехникой, начну более тесное знакомство с МК именно с ардуины.
Вы кстати в предыдущем ответе писали, что она стоит пару баксов. Укажите пожалуйста, где я могу их купить по этой цене. Минимальное что я нашел - от 800 р.
Насчет кнопки - я как бы и не упоминал про МК. Я привел именно такой пример, чтобы показать с чем именно у меня возникают проблемы. Если бы я не умел программировать для МК, я бы и его включил в пример =)
Даже если брать ардуино, то все равно нужно подключать как минимум какие-то дополнительные компоненты, которые можно спалить вместе с ардуиной если неправильно все рассчитать.
Паять я уже и сейчас могу найти что, только знать бы что паять правильно, а не все подряд. Именно поэтому мне и нужна информация по этой теме. Я предпочитаю сперва читать manual, а уже потом браться за паяльник.
Александр Евсеев: спасибо за гайд и все остальные советы. Насчет CQRS я читал ранее, но только сейчас подумал, что этой действительно может подойти мне)
Спасибо за помощь
Здравствуйте Александр.
В первую очередь большое спасибо за ответ и за полезные ссылки.
Я ознакомился с содержимым большинства из них, но для меня по-прежнему остается непонятным, какой же подход при построении архитектуры использовать.
Допустим я буду использовать луковую архитектуру, тогда все равно у нас остаются сервисы и репозитории. В сервисах у нас бизнес логика, в репозиториях доступ к данным. И опять встает вопрос как правильно с этими данными оперировать.
Вернусь к примеру, что я приводил ранее - то ли стоит делать кучу методов в классе репозитория с почти идентичной функциональностью (SetUserValid, SetUserInvalid, SetUserFail), или стоит все таки делать методы для получения соответствующих идентификаторов и проставлять их в доменном объекте, а затем отдавать на обновление в репозиторий?
Мне хотелось получить именно best practice к построению архитектуры, чтобы не наступать на грабли, которые до меня кто-то уже собрал...
Проблему решил. Просто создал внутри процедуры переменную, которую сразу инициализирую переданной @ReportDate, а потом эту переменную передаю в функцию. Однако вопрос остался. Почему нельзя напрямую передавать переменные и SQL не ругается на это
В ходе изучения обнаружил что конкретно вызывает зависание запроса:
Когда в процедуре я вызываю функцию, я указываю в параметрах @ReportDate. Если указать вместо @ReportDate например '2014-09-01', то процедура отлично отрабатывает и не возникает проблем.
Как это победить?
Спасибо за помощь, уже проблему решили так сказать не в лоб. Просто выгрузили базу в Access и написали запросы для отчетов, это всех в принципе устроило.
@kid-programmer как раз для таких случаев хорошо подходит Unity. Он позволяет прописывать зависимости в xml формате в конфигурационных файлах.
Кстати я тоже заинтересован в ответе на поставленный в этой теме вопрос. Удалось что-либо выяснить?
Алексей, большое спасибо Вам за ссылки и ответ. Сейчас пойду изучать приведенный материал, и надеюсь он откроет мне глаза на то, как правильно использовать N-layer архитектуру.
Вопрос некоторое время подержу открытым, вдруг кто-то еще поделится своим опытом, если этого не произойдет - помечу Ваш ответ как решение.
Многие разработчики путают эти две архитектуры, называя N-Tier'ом N-Layer архитектуру, именно поэтому в названии темы я перечислил обе архитектуры, чтобы привлечь внимание и тех и других. В самом же тексте вопроса я неоднократно называл каждый из проектов - слоями.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
