ИМХО, как-то у Вас все хардкорно. Маленькая библиотека — прям фрэймворк, который указывает на необходимый дизайн приложения и вносит зависимости (интерфейсы). При это все, что требуется для тестового набора — получить базу.
Так как данный подход очень мало распространен в .NET — почти нет никаких готовых библиотек для его реализации.
Для ускорения, пустая база со схемой создается во время компиляции (post-build). А после, в каждом тесте/наборе, файл копируется и присоединяется (простой скрипт на master: CREATE DATABASE [...] ON (filename = ...)[, (filename = ...)]).
За наполнение данными отвечает сам тестируемый модуль, т.к. не всегда БД это только лишь CRUD, иногда есть поток сообщений/событий, из которого создаются проекции. Заодно и последнее тестируется.
Что касается "медленно" — так тут уже решается в рамках проекта, что и как тестировать. Как подсказали, иногда снэпшоты помагают. А иногда и разделение кода по репозиториям, как и сама оптимизация работы продукта.
кстати, немного по теме DDD, SQRS, ES. есть англоязычная чат группа на slack, в основном так люди с бэкграундом .net. довольно многие если что ответят/подскажут.
началось так: https://twitter.com/randompunter/status/681830829203533824
Операции (комманды и квейри) могут быть выполнены за пределами 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). Само использование таких компонентов позволяем избавиться от дополнительных зависимостей между ними в приложении (разве что фрэймворк которых и так идет "из коробки").
Так в этом случае и нужно в каждый репозиторий кидать настройки, т.к. они могут быть разные в каждом репозитории как и у каждой команды. Смысл микросервисов в том, что каждый сервис может быть выкинут и переписан по-новой.
Очень надеюсь не слышать термин DDD как «проблемно-ориентированном проектировании», предпочитаю использовать «предметно».
А то всегда всплывает в голове книга Нильссона в русском варианте — яркий пример как не стоит переводить техническую литературу.
Еще бы оставил оригинальные термины в переводе (хоть в скобках) — единый язык (ubiquitous language).
Та же проблема с Z1C, причем даже не падал, в кармане с ключами лежал пол дня, а как приехал домой — паутина и тач перестал работать. Думаю что больше не буду иметь дело с ювелирными телефонами.
А вот в Нидерландах как раз наоборот, в новых кварталах — центральное отопление вместо котла в каждом доме. Оплата идет все-равно по счетчику, который для потребителя будет намного дешевле газового котла (газ тут получается самый дорогой из всех остальных сервисов).
Ну так установите студию 15-ю и запускайте на IIS, основное преимущество что во время разработки нет необходимости держать тот же IIS. До релиза все может поменяться еще.
Кстати, теперь все переименовали:
k -> dotnet
kre -> xre (.Net cross-platform runtime engine)
kvm -> dotne sdk
kpm -> nuget
Предпочитаю MobaXterm, т.к. у него есть поддержка X Server и все работает без необходимости устанавливать и настраивать VNC и тому подобного. Так у меня висит где-то Ubuntu Server с установленным ubuntu-desktop и могу удаленно запускать те же Firefox, Sublime… с сервера прямо из windows.
подправлю:
1. не уверен что есть возможность, по крайней мере для kennismigrant в этом смысле все ограничено
2. экзамен супруге не нужен, другой вопрос собственно найти работу
А с этим может быть сложно. Лучше всего при переезде договариваться сразу на то, сколько вы будете получать чистыми, чтоб не удивляться потом. Я пока поработал в двух компаниях и беседовал с ребятами еще из других — все отличается. Например, в предыдущей моей компании годовая брутто была небольшой, но в месячную зарплату были включены 8% отпускных, покрывалась половина страховки меня и жены, покрывалась большая часть пенсии, транспорт, часть обедов, скидки, покупка велосипеда/скутера, был неплохой релокационный пакет, были ежегодные обязательные бонусы, покрывали обучения для меня и жены. Сейчас у меня годовая ставка брутто гораздо выше, 8% не включены, выдаются раз в год, почти нет других плюшек вроде покрытия страховки. Получаю конечно больше чем на предыдущем месте работы, но не на много, а если смотреть на разницу в брутто, то я очень сильно поднялся.
Если же ваш вопрос про то, на какую зп претендовать, то я не могу ответить, я вас не знаю, как и не знаком со всеми областями :)
Могу повторить слова моего друга: «создается ощущение что для .net разработчика потолок 4500 грязными», от себя — всегда есть исключения.
тут таборов не замечено, есть подозрение что нет вообще. гетто — скорее некоторые неприятные районы в которых не хочется находиться, а порой может и что-либо произойти.
не совсем: https://github.com/dotnet/standard/blob/master/docs/faq.md#is-appdomain-part-of-net-standard
AppDomain есть, но только частично, к примеру, нельзя создавать вторичные домены.
А вот алиасы для рефлексии есть: https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Extensions/src/System/AppDomain.cs#L241
ИМХО, как-то у Вас все хардкорно. Маленькая библиотека — прям фрэймворк, который указывает на необходимый дизайн приложения и вносит зависимости (интерфейсы). При это все, что требуется для тестового набора — получить базу.
Подход распространен, нет смысла создавать библиотеку вокруг System.Data.SqlLocalDb. Пример, https://github.com/damianh/SqlStreamStore/blob/master/src/SqlStreamStore.MsSql.Tests/MsSqlStreamStoreFixture.cs
А для простых вставок данных (если абстрагироваться от логики самого приложения), достаточно и dapper-dot-net как легковесного решения (как пример подхода с минимумом абстракций).
У нас обычный тест выглядит так:
Для ускорения, пустая база со схемой создается во время компиляции (post-build). А после, в каждом тесте/наборе, файл копируется и присоединяется (простой скрипт на master: CREATE DATABASE [...] ON (filename = ...)[, (filename = ...)]).
За наполнение данными отвечает сам тестируемый модуль, т.к. не всегда БД это только лишь CRUD, иногда есть поток сообщений/событий, из которого создаются проекции. Заодно и последнее тестируется.
Что касается "медленно" — так тут уже решается в рамках проекта, что и как тестировать. Как подсказали, иногда снэпшоты помагают. А иногда и разделение кода по репозиториям, как и сама оптимизация работы продукта.
кстати, немного по теме DDD, SQRS, ES. есть англоязычная чат группа на slack, в основном так люди с бэкграундом .net. довольно многие если что ответят/подскажут.
началось так: https://twitter.com/randompunter/status/681830829203533824
с чего вы это взяли? [http://martinfowler.com/bliki/CQRS.html]
могут, но в момент написания кода мы уже знаем контекст в котором будем выполнять команду или запрос. и код будет сильно отличаться в зависимости от контекста:
никто не может запретить вам этого. я веду к тому что контекст — важная часть при принятии архитектурных решений от которой никуда не деться. не нравиться хранить код в завязанных на фрэймворк классах — выделите в отдельный чистый и вызывайте оттуда (хотя мое правило — только при необходимисти, как переиспользование функционала либо когда у кода разная ответственность). а излишние абстракции только усложняют код и вносят ограничения на реализацию возможностей инфраструктуры.
итого:
а потом:
возникает вопрос — зачем такая сложность (accidental complexity)?
SomeEntityListOperation — абстракция от WebApi контроллера:
Касательно компонентов в других сборках — уже также есть довольно популярное решение: middleware (например, специфиципровано в owin и реализовано в katana и, кстати, поддерживает WebApi). Само использование таких компонентов позволяем избавиться от дополнительных зависимостей между ними в приложении (разве что фрэймворк которых и так идет "из коробки").
А если распаковать то и все 40+гб
А то всегда всплывает в голове книга Нильссона в русском варианте — яркий пример как не стоит переводить техническую литературу.
Еще бы оставил оригинальные термины в переводе (хоть в скобках) — единый язык (ubiquitous language).
Варианты домой и отоплений можно брать с funda.nl, смотреть на год постройки и тип отопления. Например, www.funda.nl/koop/utrecht/huis-47649341-pimpernelstraat-28/kenmerken
Построен (Bouwjaar) — 2000
Отопление (Verwarming) — Центральное/городское (Stadsverwarming)
stackoverflow.com/questions/27325264/asp-net-5-project-hosting-on-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 — стандартно либо через нативный модуль.
Здесь EUR 5,300.64, это вот уже запредельная сумма, а 4,743 в принципе возможно достичь (по-моему).
1. не уверен что есть возможность, по крайней мере для kennismigrant в этом смысле все ограничено
2. экзамен супруге не нужен, другой вопрос собственно найти работу
Если же ваш вопрос про то, на какую зп претендовать, то я не могу ответить, я вас не знаю, как и не знаком со всеми областями :)
Могу повторить слова моего друга: «создается ощущение что для .net разработчика потолок 4500 грязными», от себя — всегда есть исключения.