Pull to refresh
6
0
Михаил Рыбников @mihasic

User

Send message

ИМХО, как-то у Вас все хардкорно. Маленькая библиотека — прям фрэймворк, который указывает на необходимый дизайн приложения и вносит зависимости (интерфейсы). При это все, что требуется для тестового набора — получить базу.


Так как данный подход очень мало распространен в .NET — почти нет никаких готовых библиотек для его реализации.

Подход распространен, нет смысла создавать библиотеку вокруг System.Data.SqlLocalDb. Пример, https://github.com/damianh/SqlStreamStore/blob/master/src/SqlStreamStore.MsSql.Tests/MsSqlStreamStoreFixture.cs
А для простых вставок данных (если абстрагироваться от логики самого приложения), достаточно и dapper-dot-net как легковесного решения (как пример подхода с минимумом абстракций).


У нас обычный тест выглядит так:


  • получить базу (connection string)
  • накатить схему
  • добавить тестовые данные
  • выполнить сам тест
  • очистить ресурсы

Для ускорения, пустая база со схемой создается во время компиляции (post-build). А после, в каждом тесте/наборе, файл копируется и присоединяется (простой скрипт на master: CREATE DATABASE [...] ON (filename = ...)[, (filename = ...)]).


За наполнение данными отвечает сам тестируемый модуль, т.к. не всегда БД это только лишь CRUD, иногда есть поток сообщений/событий, из которого создаются проекции. Заодно и последнее тестируется.


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

кстати, немного по теме DDD, SQRS, ES. есть англоязычная чат группа на slack, в основном так люди с бэкграундом .net. довольно многие если что ответят/подскажут.
началось так: https://twitter.com/randompunter/status/681830829203533824

CQRS как архитектурный паттерн — это в первую очередь про абстрагирование бизнес-логики от инфраструктурного слоя и структурирование кода

с чего вы это взяли? [http://martinfowler.com/bliki/CQRS.html]


Операции (комманды и квейри) могут быть выполнены за пределами WebApi (WCF, ServiceStack, Akka.NET,...) и Web-контекста в целом (например, отправлены в очередь).

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


  • для HTTP (WebApi. NancyFX, ServiceStack...) всегда можно использовать специфичные техники (ETag, client cache...)
  • для actor-framework (akka, orleans), это специфичный только там код
  • WCF — с моей точки зрения отдельная тема (я бы не использовал технологию, пока не прийдется — например, интеграция с особенными протоколами)
  • Service Bus — как и с перечисленным выше, это такой же контекст, архитектурное решения, которое влияет на весь остальной код

Есть еще много причин, почему я не хочу хранить бизнес-логику в теле методов контроллеров (пусть и WebApi), но это очень длинная тема и я не хочу ее развивать.

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

итого:


Задача
Избавить прикладных разработчиков от необходимости написания контроллеров, проекций и сервисов.

а потом:


По шагам
Добавляем SomeEntity: IEntity
Добавляем SomeEntityListDto
Регистрируем маппинг SomeEntity -> SomeEntityListDto
Автоматом получаем метод /SomeEntity/List
Дописываем бизнес-логику в SomeEntityListOperation<SomeEntity, SomeEntityListDto>
Метод /SomeEntity/List начинает использовать новую реализацию с «правильной» бизнес-логикой

возникает вопрос — зачем такая сложность (accidental complexity)?


SomeEntityListOperation — абстракция от WebApi контроллера:


  • url операции может быть объявлен через аттрибут
  • задачу DI зависимостей в контроллер уже как бы решили
  • автоматом получаем content negotiation
  • нет необходимости внедрения костылей при требовании кэширования и т.п.: ETag, Expiration, HEAD request etc.
  • авторизация тоже поддерживается и настраивается по разным операциям
  • нет необходимости сканировать все типы сборки(ок)

Касательно компонентов в других сборках — уже также есть довольно популярное решение: middleware (например, специфиципровано в owin и реализовано в katana и, кстати, поддерживает WebApi). Само использование таких компонентов позволяем избавиться от дополнительных зависимостей между ними в приложении (разве что фрэймворк которых и так идет "из коробки").

тяжеловат, весит около 10 ГБ

А если распаковать то и все 40+гб
Так в этом случае и нужно в каждый репозиторий кидать настройки, т.к. они могут быть разные в каждом репозитории как и у каждой команды. Смысл микросервисов в том, что каждый сервис может быть выкинут и переписан по-новой.
Очень надеюсь не слышать термин DDD как «проблемно-ориентированном проектировании», предпочитаю использовать «предметно».
А то всегда всплывает в голове книга Нильссона в русском варианте — яркий пример как не стоит переводить техническую литературу.

Еще бы оставил оригинальные термины в переводе (хоть в скобках) — единый язык (ubiquitous language).
Та же проблема с Z1C, причем даже не падал, в кармане с ключами лежал пол дня, а как приехал домой — паутина и тач перестал работать. Думаю что больше не буду иметь дело с ювелирными телефонами.
А вот в Нидерландах как раз наоборот, в новых кварталах — центральное отопление вместо котла в каждом доме. Оплата идет все-равно по счетчику, который для потребителя будет намного дешевле газового котла (газ тут получается самый дорогой из всех остальных сервисов).

Варианты домой и отоплений можно брать с funda.nl, смотреть на год постройки и тип отопления. Например, www.funda.nl/koop/utrecht/huis-47649341-pimpernelstraat-28/kenmerken
Построен (Bouwjaar) — 2000
Отопление (Verwarming) — Центральное/городское (Stadsverwarming)
мне полный IIS на машине не нужен, а вот ответ на вопрос:
stackoverflow.com/questions/27325264/asp-net-5-project-hosting-on-iis
Ну так установите студию 15-ю и запускайте на IIS, основное преимущество что во время разработки нет необходимости держать тот же IIS. До релиза все может поменяться еще.
Кстати, теперь все переименовали:
k -> dotnet
kre -> xre (.Net cross-platform runtime engine)
kvm -> dotne sdk
kpm -> nuget

www.youtube.com/playlist?list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF (последнее видео от 12-01-2015).

В том же видео рассказывают как оно внутренне будет работать на IIS — стандартно либо через нативный модуль.
www.eubluecard.nl/news/news_item/t/highly_skilled_migrant_salary_threshold_2015
Здесь EUR 5,300.64, это вот уже запредельная сумма, а 4,743 в принципе возможно достичь (по-моему).
В нашей компании весь девелопмент перешел на flowdock вместо почты и пока что счастливы.
Предпочитаю MobaXterm, т.к. у него есть поддержка X Server и все работает без необходимости устанавливать и настраивать VNC и тому подобного. Так у меня висит где-то Ubuntu Server с установленным ubuntu-desktop и могу удаленно запускать те же Firefox, Sublime… с сервера прямо из windows.
подправлю:
1. не уверен что есть возможность, по крайней мере для kennismigrant в этом смысле все ограничено
2. экзамен супруге не нужен, другой вопрос собственно найти работу
А с этим может быть сложно. Лучше всего при переезде договариваться сразу на то, сколько вы будете получать чистыми, чтоб не удивляться потом. Я пока поработал в двух компаниях и беседовал с ребятами еще из других — все отличается. Например, в предыдущей моей компании годовая брутто была небольшой, но в месячную зарплату были включены 8% отпускных, покрывалась половина страховки меня и жены, покрывалась большая часть пенсии, транспорт, часть обедов, скидки, покупка велосипеда/скутера, был неплохой релокационный пакет, были ежегодные обязательные бонусы, покрывали обучения для меня и жены. Сейчас у меня годовая ставка брутто гораздо выше, 8% не включены, выдаются раз в год, почти нет других плюшек вроде покрытия страховки. Получаю конечно больше чем на предыдущем месте работы, но не на много, а если смотреть на разницу в брутто, то я очень сильно поднялся.

Если же ваш вопрос про то, на какую зп претендовать, то я не могу ответить, я вас не знаю, как и не знаком со всеми областями :)
Могу повторить слова моего друга: «создается ощущение что для .net разработчика потолок 4500 грязными», от себя — всегда есть исключения.
тут таборов не замечено, есть подозрение что нет вообще. гетто — скорее некоторые неприятные районы в которых не хочется находиться, а порой может и что-либо произойти.
сам возврат пока не делал (вроде до 5 лет на это есть), большинство русскоговорящих советовали обращаться к nalog.nl

Information

Rating
Does not participate
Location
's-Gravenhage, Zuid-Holland, Нидерланды
Date of birth
Registered
Activity