• Время смелых. Как мигрировать в облака, не нарушая требований регуляторов?
    0

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


    Сегмент «Закрытый» реализован с использованием решений VMware. Инфраструктура соответствует требованиям приказов №17 и №21 ФСТЭК для обеспечения до 1-го класса защиты ГИС и 1-го уровня защищенности ПДн включительно. Собственно говоря, решение позволяет, в том числе, государственным органам размещать ИС с наивысшими требованиями к информационной безопасности, что подтверждается наличием аттестата соответствия требованиям защиты информации, установленным ФСТЭК России.

    Предположим, что коммерческая компания, хочет разместить в вашем облаке SaaS-решение, предназначенное для органов государственной власти или органов местного самоуправления. Приложение является системой обработки ПДн. И поскольку ИС обработки ПДн — это не только сервера, но и ПО, а также клиентские рабочие места и сеть, то:


    • как сертифицируется само ПО, которое такая компания-разработчик размещает и требуется ли такая сертификация?
    • как сертифицируются клиентские рабочие места конкретного заказчика — пользователя SaaS-решения, а также каналы связи с ним?
    • как сертифицируются клиентские рабочие места сотрудников компании-разработчика SaaS-решения, с которых выполняются работы по обслуживанию системы, а также каналы связи?
    • какие бумаги, гарантирующие что конкретный заказчик (пользователя SaaS-решения) исполняет закон о защите ПДн, вы предоставляете?
  • Обратная сторона Agile
    0
    Keks650, подскажите, а какой процесс использовался до перехода? он как-то был описан, сформулирован, осознан? или люди просто интуитивно правильно работали?
  • Бесплатный пакет возможностей для разработчика: Visual Studio Dev Essentials
    0
    Подскажите пожалуйста, какую "кучу плюшек" можно получить на 25$ в Azure? Особенно интересно было бы в сравнении c программой Amazon Web Services Free Tier?
  • IDE от JetBrains теперь доступны только в аренду
    +8
    Возможно, но когда столько перечеркнутых сумм и звездочек со сносками, очень сложно понять, какова же все-таки цена. 119 для существующих пользователей-это для тех, у кого уже есть решарпер? А для новых людей в команде?
    Основная у нас VS 2012 и к ней достаточно давно куплены решарперы. На 2013 многие не переходили, в основном из-за необходимости обновлять решарпер. С 2015-й ситуация другая, перейти на нее хочется всей коммандой, но даже при пожизненной лицензии убедить выделить средства на обновление пока не удается. Все-таки это не IDE, а ускорение работы в ней, и некоторым кажется, что можно «легко обойтись». Теперь же вместе с выделением денег на продление нужно еще и смириться с тем что, это только на год, а в следующем году нужно будет платить еще раз. Хотя вероятность перехода с VS 2015 через год не очень велика. Добавьте к этому новые курсы валют и появление light bulbs в VS 2015, и пропасть между разработчиком и лицом, разрешающим покупку, становится почти непреодолимой.
  • IDE от JetBrains теперь доступны только в аренду
    +27
    Выскажусь относительно ReSharper-а. И до сегодняшнего дня в нашей компании, к примеру, было сложно объяснить руководству, почему нужно платить 250 долларов на разработчика за этот, пусть и реально полезный, продукт. Теперь же нужно, будет платить 250 ежегодно. Если раньше мы могли спокойно сидеть на старой версии Vs больше года, то теперь так не выйдет. Кстати, надо отметить что Макрософт даёт 5 Vs Community вообще бесплатно.
    В общем, все это грустно. Хочется надеяться, что с появлением Roslyn все же появятся достойные аналоги решарпера бесплатно или за разумные деньги.
  • Пять признаков того, что вы должны сейчас же нанять этого программиста
    +2
    Это позволяет нам оценить производительность программиста, основываясь исключительно на времени выполнения задания: если все решено меньше, чем за час, мы будем довольны

    А если потом в реальной работе программист решает задачу вот так, за час, а после этого тратит еще три раза по часу, чтобы сделать код не просто рабочим но и правильным/красивым/обобщенным и т.п., вместо того, чтобы потратить сразу два или два с половиной часа и сделать все то же самое? Насколько объективна оценка программиста с позиции такой «производительности»?
  • Управление разработкой программного продукта на основе рисков
    0
    Интересно, а есть ли примеры, где сами разработчики/менеджеры реальных проектов описывают свой процесс управления рисками? В блогах, например? Они его как-то формализуют или управление рисками происходит на уровне «ощущений и инстинктов»?
  • Что нового в Visual Studio 2015 для JS-разработчиков
    0
    Еще было бы здорово, если бы VS когда-нибудь получила intellisense при написании angular-выражений в html-шаблонах. Ну и рефакторинг соответственно.
  • Путь аналитика. Работа над ошибками
    0
    А как вы разграничиваете роли аналитика, архитектора и проектировщика? Мне, честно говоря, тоже странно выполнение одним человеком ролей архитектора и аналитика одновременно. Я бы в этом случае предположил, что этот же человек и основной разработчик тоже.
  • Опыт разработки и проектирования на AngularJS
    0
    Например, я хочу несколько директив, которые по сути своей dropdown-контролы, но содержимое выпадающей области разное: в одном случае простой список, в другом — какая-то более ложная конструкция, позволяющая искать/выбирать элементы. В силу того, что большую часть времени я пишу на языке с наследованием, мне описанное разнообразие хочется сделать с помощью соответствующих классов-наследников. Хотя, require, похоже тоже для этого подойдет.
  • Путь аналитика. Работа над ошибками
    0
    А какое отношение в описанной компании было к agile-технологиям разработки?
  • Опыт разработки и проектирования на AngularJS
    0
    Спасибо!
    Еще попутно вопрос по структурированию кода приложения: где, по Вашему мнению, лучше размещать логику построения (перестроения) DOM, общую для нескольких директив? Ведь наследования директив нормальными способами не добиться?
  • Опыт разработки и проектирования на AngularJS
    0
    Но ведь эти проблемы связаны не непосредственно с AngularJs, я правильно понимаю? Т.е. понятно, что резиновый интерфейс не всегда позволяет сделать интерфейс удобным для всех форм-факторов, а косяки с разметкой могут быть разные в разных браузерах. Но если все-таки этот путь выбран (хотя бы как временный), то как себя будет вести AngularJs со своим двусторонним связыванием в мобильном браузере? В аспекте производительности и в аспекте совместимости AngularJs с разными браузерами…
  • Опыт разработки и проектирования на AngularJS
    +1
    Интересно было бы узнать о применении AngularJs для разработки Web-приложений, работающих в браузере мобильных устройств. Как в этом случае трансформируются рекомендуемые ограничения по количеству watch-ей на странице? Было бы здорово еще и узнать о каких-нибудь примерах из реального опыта.
  • Entity Framework глазами постороннего
    +1
    Думаю, ответ вовсе не очевиден! Почему CodeFirst так быстро набирает популярность и фактически становится приоритетным подходом при использовании EF?
    Кроме того, одна из задач ORM, избавить разработчика бизнес-логики от нюансов системы хранения и сделать модель предметной области чистой. И в этом смысле работая с диаграммой классов, я именно проектирую такую модель. Естественно, вопрос отображения этой модели в БД тоже важен. Но решается он не визуально на диаграмме, а в коде, и меня лично это совсем не смущает, поскольку те места, где это отображение определяется при использовании fluent api, заведомо известны.
    Но у меня тогда еще вопрос: если Вы используете некую «замечательную» альтернативу EF, которая позволяет делать все гораздо удобнее, то она либо «серебряная пуля» (но Вы сами в одном из комментариев признали, что ее нет), либо что-то, обладающее другими недостатками. Так давайте же тогда озвучим эту альтернативу и будем сравнивать EF, не с потенциальными «пожеланиями» к ORM, а с реальным конкурентом. Иначе, как-то однобоко получается.
  • Entity Framework глазами постороннего
    +5
    CodeFirst… Поэтому мне нужны картинки. Компактные, наглядные, удобные. Причем модель должна быть не на одной картинке, а на нескольких, по-частям, выбранным как-то предметно. Ну, и далее, с картинок что-то как-то должно генерироваться, не буду же я писать однотипный код сотнями раз, да ещё и не делать при этом ошибок.

    А почему для визуализации модели нельзя в случае с CodeFirst использовать диаграммы классов? Они, по-моему, удовлетворяют описанным требованиям?
  • Entity Framework или почему я реализую Repository
    0
    А каким был интерфейс репозитория? Универсальным, т.е. выставлялся IQueryable или его аналог, или просто содержал конечный набор методов, который и определял набор возможных запросов?

    И еще интересно было бы узнать Ваше мнение. Допустим в некой задаче нет необходимости поддерживать разные хранилища/ORM, есть только EF и, к примеру, SQL Server. Но в то же время набор возможных запросов к БД сильно ограничен и расширяется очень предсказуемо. Стали бы Вы оборачивать EF в репозиторий с простым интерфейсом, или же просто использовали бы DbContext?
  • Entity Framework или почему я реализую Repository
    0
    Ну теперь, вроде бы, позиции наши ясны. Спасибо, lair, за дискуссию! Было интересно!
    Кстати говоря, здорово было бы Вам написать пост по материалам комментариев к этой статье: Вы, по моему, большую работу проделали по разъяснению. Осталось только все это собрать вместе.
  • Entity Framework или почему я реализую Repository
    0
    Нет, ее посыл в том, что IQueryable — это текущая абстракция, которая не предоставляет изоляции. Если это осознавать, равно как и осознавать ограничения этого — все будет хорошо.
    А эти слова разве я написал в начале статьи?
    From time to time I encounter people who attempt to express an API in terms of IQueryable. That's almost always a bad idea. In this post, I'll explain why

    На всякий случай напомню, что я написал почти то же самое:
    весь ее посыл в том, чтобы не использовать этот интерфейс в своем API


    Вам кажется. На самом деле, речь идет о замене ORM за абстрактным интерфейсом
    Когда мне говорят, что мне кажется, а собеседник знает, как «на самом деле», я очень настораживаюсь: возможно у человека сверхспособности. Боюсь что в данном случае у нас с Вами просто разный прошлый опыт и набор тех проблем, с которыми мы сталкивались. Поэтому Вы смотрите на это в своем контексте, а я в своем. А кто из нас «на самом деле» прав, может сказать только Марк Симан.

    Если вы предполагаете заменять хранилище — тогда зависимость от IQueryable плоха (потому что его реализации не взаимозаменяемы). Если нет — то нет.
    Но заметьте, что автор ответа на SO (он же и автор вопроса) нигде не говорит о том, что собирается заменять NHibernate. И тем не менее, он зачем-то инкапсулирует IQueryable внутри репозитория.

    как только мы отбираем IQueryable, мы берем на себя обязанность предоставить замену. Банальный пример: как в предложенном DSL выразить запрос на (а) начатые и незавершенные (б) начатые или незавершенные? А проекции? А джойны? Ну и понеслась. А интеграция с UI и сервисной моделью навроде OData?
    А вот тут я с Вами полностью согласен. Как только у нас появляется разнообразие запросов, мы будем изобретать велосипед, создавая нечто такое же гибкое, как IQueryable, с теми же проблемами. Вопрос только в том, всегда ли нужно такое разнообразие и те возможности, о которых Вы написали.
  • Entity Framework или почему я реализую Repository
    +1
    Понятно. Но насчет Симана я не соглашусь: по-моему Вы отделяете приведенное Вами ранее высказывание от контекста.
    If you have a specific ORM in mind, then be explicit about it. Don't hide it behind an interface. It creates the illusion that you can replace one implementation with another. In practice, that's impossible. Imagine attempting to provide an implementation over an Event Store.
    Во-первых, статья называется «IQueryable is Tight Coupling» и весь ее посыл в том, чтобы не использовать этот интерфейс в своем API. Мне даже кажется, что Симан считает, что IQueryable вообще не стоило разрабатывать, поскольку абстракция «дырявая» до неприличия. Хотя непонятно, как тогда стоило бы поступить.
    Во-вторых, в приведенной цитате я бы выделил фразу «It creates the illusion that you can replace one implementation with another». Возникает вопрос: implementation of what? Мне кажется, что речь об интерфейсе IQueryable.
    В-третьих, в подтверждение этого есть комментарий к статье с просьбой к Марку оценить интерфейс репозитория над NHibernate:
    What do you think about the API outlined in this post: http://stackoverflow.com/a/9943907/572644
    И вот ответ Марка:
    Looks good, Daniel. I'd love to hear your experience with this once you've tried it on for some time
    По ссылке на StackOverflow есть пример кода, где IQueriable скрыт за своим интерфейсом, который уже не предоставляет IQueryable.

    Только это уже какая-то герменевтика пошла…
  • Entity Framework или почему я реализую Repository
    0
    Тогда получается, что если мы используем EF в качестве ORM (или, кстати говоря, C# LINQ driver над MongoDb), то репозиторий и не нужен? Или есть все-таки какие-то условия, при которых нам стоит ввести репозиторий и скрыть ORM и в том числе IQueryable?
  • Entity Framework или почему я реализую Repository
    +1
    Выставить наружу IQueryable это довольно слабое ограничение. Множество всевозможных запросов, построенных с его помощью, со временем может очень вырасти. Унификация с помощью методов-расширений к IQueryable, как я понимаю, не ограничит разнообразие запросов: ведь я по-прежнему могу писать запросы на «чистом» LINQ. А насчет «построителя для expression» что имеется ввиду? И главное, как это ограничит для потребителей возможность писать чистые LINQ-запросы?
  • Entity Framework или почему я реализую Repository
    0
    Вы имеете ввиду, что набор возможных запросов к репозиторию со временем разрастается так, что лучше иметь IQueryable или его аналог?
  • Entity Framework или почему я реализую Repository
    0
    Я правильно понимаю, что через интерфейс IFooDbContext вы отдаете потребителям IQueryable<A> и IQueryable<B>?
    interface IFooDbContext
    {
      IQueryable<A> A {get;}
      IQueryable<B> B {get;}
    }
    
    Если так, то как мы решаем проблему «зверинца» запросов от потребителей? Хочется ведь их свести вместе и ограничить-таки интерфейс DbContext-а.
  • Entity Framework или почему я реализую Repository
    +1
    Мне почему-то кажется, что это не намного проще. Если я правильно понимаю, это замена композиции наследованием? И здесь меня смущают следующие моменты.
    1. Ограничение доступа к DbContext-у очень условное: т.е. можно конечно коду-потребителю передавать IFooDbContext и там будет только то, что мы туда внесли. Но ведь пытливый разработчик может всегда привести его к типу FooDbContext и получить тот же DbSet и снова начать плодить «зверинец» разнообразных запросов. Конечно, в случае замены наследования композицией можно тоже взять Reflection и сделать все, что хочется, но это уже явный «хак», на который просто так никто не решится.
    2. Что если мы захотим написать unit tests к методам GetFooByParamSet1 и т.д.? Как мы заменим сам DbContext каким-нибудь mock-объектом?
  • Entity Framework или почему я реализую Repository
    0
    Т.е. получается что-то вроде:
    public class FooRepo {
      private FooDbContext _dbContext;
    
      public FooRepo() {
         _dbContext = new FooDbContext();
      }
      public GetFooByParamSet1(paramSet1) { ... }
      public GetFooByParamSet2(paramSet2) { ... }
      ...
      public AddFoo() {}
      public RemoveFoo() {}
      ...
      public SaveChanges() {}
    }
    

    Если я правильно понимаю, получается обертка над DbContext-ом, которая одновременно и UoW и Репозиторий?
  • Entity Framework или почему я реализую Repository
    0
    Тогда все же хочется понять Ваш подход.
    Пусть мы имеем РСУБД, даже конкретно SQL Server, и храним в ней данные модели предметной области. Для точности пусть это будут DDD-агрегаты типа Foo с какой-то внутренней структурой. Для маппинга используем EF и получаем объекты Foo через DbSet<Foo>.
    В то же время обобщенный интерфейс DBSet-ов нас не устраивает в том плане, что в разных местах системы, где он используется будет «зверинец» LINQ-запросов, в том числе и повторяющихся. Логично, вроде бы, в этом случае ввести над DbSet<Foo> какой-то репозиторий FooRepo, в интерфейсе которого будет ограниченное число методов доступа к данным, которых достаточно для работы всего вышестоящего кода в системе. Но в то же время нам нужен UoW, чтобы мы могли модифицировать объекты группам и рамках одной транзакции. Как добавить этот UoW?
    Как бы Вы подошли к решению такой задачи?
  • Entity Framework или почему я реализую Repository
    0
    Пришлось перечитать несколько раз. Автору стоило бы как-то выделить, на мой взгляд. Просто человеку ведь свойственно выделять из множества информации ту, которая его беспокоит больше. Вот так же вышло и со мной.
  • Entity Framework или почему я реализую Repository
    0
    А где я сказал, что репозиторий поможет решить эти проблемы?
    Похоже я в своем первом посте выразил слишком общее одобрение всему сказанному в статье. Моя вина, каюсь! Но попробую пояснить: подавляющая часть статьи содержит описание проблем, с которыми можно столкнуться при, скажем так, использовании EF «в лоб», без должного понимания. Именно к этому описанию я и попытался добавить некоторое дополнение.
    А вот это высказывание я поддержать не готов:
    я говорю да Repository, ведь все описанные проблемы легко обойти с помощью этой абстракции которая обернет EF и поглотит проблемы совместимости
    Оно вообще похоже на то, что найдена «серебряная пуля». Но мне кажется, что здесь свое дело сделали эмоции автора, ведь и стиль изложения материала в статье несколько «импульсивный», имхо. Насчет Repository над EF не хочу писать обрывками: думаю, идея полезная и может решить часть проблем, но каких и как — нужно пояснить. Попробую сформулировать это чуть позже.
  • Entity Framework или почему я реализую Repository
    0
    Как-то Вы мой пример, который приведен лишь для того, чтобы обратить внимание на возможные последствия (чаще всего, по незнанию того, «что происходит на два уровня ниже твоего уровня абстракции»), вырвали из контекста и за него меня «хлещете». Он не направлен на то, чтобы как-то упрекнуть EF. Это как раз пример того, как непонимание механизмов внутренней работы (в данном случае мое) может привести к проблеме.
  • Entity Framework или почему я реализую Repository
    0
    Отлично! Я ведь с этого и начал:
    … чтобы те, кто рассматривает возможность использования EF или других ORM в первый раз, понимали, с какими ограничениями они столкнутся в будущем, и учитывали это в своих проектных решениях
  • Entity Framework или почему я реализую Repository
    0
    В общем да. Но только как в случае с созданным поверх EF репозиторием реализовать тот же UoW, не внося путаницы уже в наш репозиторий?
  • Entity Framework или почему я реализую Repository
    +1
    Во-первых сам EF ничего не строит сам, он только интерпретирует ваш запрос
    Конечно. Но только интерпретировать он его может по-разному. И получается, что помимо LINQ я должен понимать особенности интерпретации expression tree с запросом каждым конкретным провайдером. Т.е. абстракция уже не скрывает от меня детали реализации, а значит она «течет».
    То есть проблема не в том, что EF плохой
    Я не говорил, что EF плохой! EF отличный, просто нужно понимать, что он не избавляет от необходимости хорошо понимать его работу с СУБД. Вы, кстати, наглядно аргументировали это в своем комментарии.
  • Entity Framework или почему я реализую Repository
    0
    Что именно вы считаете фасадом EF?
    В данном случае я имею ввиду DbSet<T>, который, реализуя IQueryable<T> и добавляя Add и Remove, фактически и действует как
    … in-memory domain object collection
  • Entity Framework или почему я реализую Repository
    +1
    С другой стороны там же написано [PoEAA, 2003]:
    A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer.
    И если рассматривать в качестве реализации data-mapper только часть EF, то я не вижу каких-то особенных противоречий в утверждении, что EF реализует в том числе и шаблон Repository. Ведь и в приведенной Вами цитате сказано, что:
    ...This may seem an academic distinction, but it illustrates the declarative flavor of object interaction with Repository, which is a large part of its conceptual power.
    Т.е. концептуально EF конечно не репозиторий, поскольку репозиторий более окрашен в «тона предметной области». Так же, как и Specification по сравнению с Query Object, как мне кажется. С другой стороны, формально фасад EF очень похож на описание фасада репозитория.
    Некоторые интересные мысли по поводу EF и Repository можно найти в этой дискуссии на stackexchange.com.
  • Entity Framework или почему я реализую Repository
    0
    inwake, спасибо за статью! На мой взгляд, эту тему нужно периодически поднимать, чтобы те, кто рассматривает возможность использования EF или других ORM в первый раз, понимали, с какими ограничениями они столкнутся в будущем, и учитывали это в своих проектных решениях. Как говорит Мартин Фаулер:
    Часто мне кажется, что в большой степени разочарование ORM связано с раздутыми ожиданиями
    Хотелось бы добавить к сказанному еще несколько моментов.
    1. Почти все сказанное в статье, по-моему, можно отнести ко всем ORM, поскольку все занимаются связыванием двух разных моделей представлений: объектно-ориентированной и реляционной, т.е. как-то решают вопрос с уже набившим оскомину object-relational impedance mismatch.
    2. Проблемы с производительностью могут возникать не только при выполнении одного LINQ-запроса на разных провайдерах, но и при попытке выполнить сложные запросы на одном провайдере. Например, я имел опыт написания LINQ-запроса с группировкой данных, в качестве СУБД выступал SQL Server. Я понимал, что EF построит мой запрос не оптимально, но на первых порах я не хотел заниматься оптимизацией. В итоге, проблема проявилась гораздо раньше, чем я ее ждал: получилось что при наличии 800 записей в основной таблице с данными запрос выполнялся 8 секунд, а на следующий день, когда записей в таблице стало 1200 — 14 секунд. Как выяснилось, запрос, который строил EF, содержал 8 вложенных select-выражений! В итоге тот же запрос был написан на чистом SQL с использованием только двух вложенных select-ов и все стало выполняться в пределах одной секунды.
    3. EF предоставляет нам репозиторий с максимально универсальным поисковым интерфейсом — IQueryable. И именно потому, что количество запросов, построенных с его помощью, безгранично, то разработчики конкретных LINQ-провайдеров вынуждены как-то ограничивать это множество. В итоге, мы действительно получаем то, что при работе с конкретным провайдером нужно понимать, что он поддерживает, а что нет. Т.е. особенности реализации провайдера «протекают» через абстракцию IQueryable. У Mark Seemann есть хорошая статья о том, что не нужно использовать IQueryable в интерфейсах репозитория. Хоть она и несколько категорична, почитать ее стоит.
      Разрабатывая собственный репозиторий со специализированным интерфейсом, мы в силах ограничить число возможных запросов к нему и, соответственно, обеспечить более полную реализацию.Но проблема может возникнуть тогда, когда мы должны создать достаточно универсальный репозиторий, который может хранить различные классы объектов и допускать достаточно сложные запросы. И тут нам все-равно придется либо вводить свой универсальный запросный язык, либо использовать IQueryable, ограничив набор поддерживаемых запросов и доведя это до тех, кто будет наш репозиторий использовать.
  • Плюсы микросервисной архитектуры
    +5
    А можно поинтересоваться, чем микросервисная архитектура отличается от сервис-ориентированной архитектуры (SOA)
  • Почему я не преподаю SOLID и «принцип устранения зависимостей»
    0
    И дальше два варианта: либо вы инъектируете в A и B репозиторий, передадите ему спецификацию и получите данные, либо какой-то внешний код вызовет A.GetSpecification(...) и B.GetSpecification(...), после чего запросит у репозитория данные и подсунет их через A.SetData(...) и B.Set(...). Во втором варианте, имхо, код будет запутаннее, т.е. получится ровно то, против чего возражает автор статьи.
  • Почему я не преподаю SOLID и «принцип устранения зависимостей»
    0
    Так IQueryable и будет у вас интерфейсом репозитория, только до такой степени общим, что любой репозиторий может быть его реализацией (правда, только в запросной части). В статье же предлагается передать в A и B сами данные
  • Почему я не преподаю SOLID и «принцип устранения зависимостей»
    +1
    А зачем дополнительно передавать смысл в трех словах, если само определение состоит из трех слов и наиболее точно выражает смысл?