Именно напряглись, когда эти территории уйдут обратно, население уйдет туда откуда пришло насильным способом, так же как это сделал Советский Союз в свое время с немцами
Никому не выгодно делать людей психологически устойчивыми к различным видам воздействий, так как на этом все завязано в нашем мире от политики до продаж.
Здесь речь идет не только о OneDrive, а о всей экосистеме в целом. Они так же рассказывали о всеобщей персонализации в продуктах Office и о том как это здорово.
Я думаю, что данное происходит чтобы проще было следить за предпочтениями пользователей и возможно в будущем договариваться с рекламодателями.
«Каким файлообменником ты пользуешься?» «Конечно же скайп»
А если серьезно, то данное стремление понятно, так как Microsoft на DevCon 2016 позиционировала себя именно как компания по разработке облачных технологий.
Такие же «эффективные менеджеры» просили меня сделать тестовое задание под Новый Год отняв у меня половину новогодних каникул.
К сожалению, я не приверженец лозунга «code eat sleep repeat»
С другой стороны, в вашем случае мы не можем абстрагироваться от dbContext, отсюда:
1. Сложность в написании unit тестов для бизнес логики без заведения тестового контекста и соответсвенно тестовой базы данных.(в рамках EF6, в 7 версии придумали MemoryContext)
2. Использовать Ioc-контейнер, то есть нам придется напрямую писать какой контекст мы берем.
3. Писать using(dbContext) для сборки мусора, что в какой-то мере утомительно.
В таком случае, я думаю, мы получаем сервисный слой который имплемитирует под собой функции репозитория.
Получается вы предлагаете проблему сложных выборок решить extensions-классами. Я думаю, в этом случае мы можем получить большой God-объект по всем возможным выборкам, который будет по сути напоминать репозиторий с GetProjectInStatus и так далее.
Меня очень давно мучает вопрос: как унифицировать сложные выборки при запросах из гридов, которые требуют фильтрацию, сортировку и прочее, и при этом не требовали бы больших усилий по реализации в жизнь.
По реализации выше: у меня всегда закрадывалась мысль о том, что код сам по себе избыточен и что надо как-то проще. Но данное вытекло именно из вашего подхода, так как сервисы были наводнены разными if в зависимости от того что выбрал пользователь на гриде и хотелось вынести это за рамки ответственности самого сервиса.
В случае с EF мне больше всего нравится разделять доменную модель Entities и маппинг их на базу данных на разные проекты. Так как домен ничего не должен знать о том как его сохраняют и прочее. При этом используются «богатые» модели с логикой. В этом плане мне очень нравится как все раскладывает Jimmy Bogard здесь: vimeo.com/43598193
Я думаю, что стоит начинать с книги «Экономикс» Кэмпбелл Р. Макконнелл, Стэнли Л. Брю.
А все эти ваши угадай в какую сторону пойдет тренд рынка для меня больше походит на вангование.
Просто сейчас на Android 5 все очень шустро бегает, даже на слабых аппаратах.
Я думаю, что данное происходит чтобы проще было следить за предпочтениями пользователей и возможно в будущем договариваться с рекламодателями.
А если серьезно, то данное стремление понятно, так как Microsoft на DevCon 2016 позиционировала себя именно как компания по разработке облачных технологий.
К сожалению, я не приверженец лозунга «code eat sleep repeat»
var context = new SaleDbContext();
так как напрямую обращаемся к DbSet контекста.
1. Сложность в написании unit тестов для бизнес логики без заведения тестового контекста и соответсвенно тестовой базы данных.(в рамках EF6, в 7 версии придумали MemoryContext)
2. Использовать Ioc-контейнер, то есть нам придется напрямую писать какой контекст мы берем.
3. Писать using(dbContext) для сборки мусора, что в какой-то мере утомительно.
В таком случае, я думаю, мы получаем сервисный слой который имплемитирует под собой функции репозитория.
Получается вы предлагаете проблему сложных выборок решить extensions-классами. Я думаю, в этом случае мы можем получить большой God-объект по всем возможным выборкам, который будет по сути напоминать репозиторий с GetProjectInStatus и так далее.
Меня очень давно мучает вопрос: как унифицировать сложные выборки при запросах из гридов, которые требуют фильтрацию, сортировку и прочее, и при этом не требовали бы больших усилий по реализации в жизнь.
По реализации выше: у меня всегда закрадывалась мысль о том, что код сам по себе избыточен и что надо как-то проще. Но данное вытекло именно из вашего подхода, так как сервисы были наводнены разными if в зависимости от того что выбрал пользователь на гриде и хотелось вынести это за рамки ответственности самого сервиса.
http://pastebin.com/sZYXHGv9
А все эти ваши угадай в какую сторону пойдет тренд рынка для меня больше походит на вангование.