ADO.NET Entity Framework близкое юзание

    Тем, кто пишет запросы в коде страницы посвящается...

    Приветствую всех!

    На хабре есть немного информации о том, что в следующей версии VisualStudio 2008 будет ADO.NET EntityFramework. (Открою секрет, эта версия уже появилась.) Эта разработка представляет собой универсальный фреймворк, который позволяет создавать даталогику вашего проекта в пару кликов мыши.
    До сих пор, работая с даталогикой, я сталкивался с 2 видами проектов. Первые были созданы на небезызвестном фреймворке NHibernate, другие реализовывали даталогику программистами. Я уже 3 года занимаюсь написанием и разработкой различных систем и всё это время разрабатывал логику работы с данными исключительно ручками.
    И вот, на днях, после того, как я поставил новую винду, я скачал VisualStudio WebDeveloper Express, и с радостью обнаружил в комплекте поставки ADO.NET EntityFramework. Через некоторое время зарегистрировал домен, создал простенький сайт, и начал тренировать свои силы в написании программ под этот фреймворк.


    Я был немного неприятно удивлён тем, что большинство статей о ADO.NET EF были узконаправленными. Невозможно было найти полной информации, от начала до конца, о том, как правильно настроить базу, создать сущности и произвести базовые действия над этими сущностями. Большинство статей раскрывают лишь одну из этих тем. Что-же, обучаясь, я решил поделиться опытом с тобой %username%. В то же время, используя мой код вы не сможете поднять систему работы с бизнес-процессами, но всё-таки, вы поймёте с какой стороны к чему подходить.



    Для начала необходимо создать простой Web проект с базой данных. К базе данных тоже неплохо было бы подключится сразу через DataBase Explorer. Просто потом будет удобнее.



    После этого, в проект надо добавить новый элемент «ADO.NET Entity Data Model».



    Системе надо будет указать строку для соединения с базой, а так же указать, откуда возьмётся первая модель ADO.NET EF.



    В своей БД я уже имею две очень простых таблицы Post и User, поэтому не мудрствуя лукаво, я заставил систему создать модель на основе моей БД. После всех этих, очень простых действий, я получил рабочую модель БД. Более того, изучив эту модель визуально, я не забыл заглянуть в код, и посмотреть, как же фрейворк описывает все мои классы?

    1. namespace DataBaseCore
    2. {
    3.   
    4.   /// <summary>
    5.   /// There are no comments for DbModel in the schema.
    6.   /// </summary>
    7.   public partial class DbModel : global::System.Data.Objects.ObjectContext
    8.   {
    9.     /// <summary>
    10.     /// Initializes a new DbModel object using the connection string found in the 'DbModel' section of the application configuration file.
    11.     /// </summary>
    12.     public DbModel() :
    13.         base("name=DbModel", "DbModel")
    14.     {
    15.       this.OnContextCreated();
    16.     }
    17.  
    18. /* Урезал за ненадобностью */
    19.  
    20.   [global::System.Data.Objects.DataClasses.EdmEntityTypeAttribute(NamespaceName="DataBaseCore", Name="Post")]
    21.   [global::System.Runtime.Serialization.DataContractAttribute(IsReference=true)]
    22.   [global::System.Serializable()]
    23.   public partial class Post : global::System.Data.Objects.DataClasses.EntityObject
    24.   {
    25.     /// <summary>
    26.     /// Create a new Post object.
    27.     /// </summary>
    28.     /// <param name="id">Initial value of Id.</param>
    29.     public static Post CreatePost(int id)
    30.     {
    31.       Post post = new Post();
    32.       post.Id = id;
    33.       return post;
    34.     }
    * This source code was highlighted with Source Code Highlighter.


    Намётанный глаз специалиста по работе с даталогикой показал наличие достаточно простого и изящного класса, который позволил работать как с постами в системе, так и с пользователями.

    Ну, что же, код у нас уже есть, осталось только его начать использовать. И тут, нам открываются все прелести и возможности ASP.NET. Среди немалого количества источников данных на странице я увидел Entity Data Source, который с удовольствием предоставляет данные по запросу из нашего класса. Перетаскиваем его на форму, запускаем мастер настройки, и быстренько цепляем датасорс на нашу таблицу постов.



    Несомненно, намного приятнее стало выглядеть описание датасорца в ASPX коде.
    1. <asp:EntityDataSource ID="dsPosts" runat="server" ConnectionString="name=DbModel"
    2.     DefaultContainerName="DbModel" EntitySetName="Post">
    3.   </asp:EntityDataSource>
    * This source code was highlighted with Source Code Highlighter.

    Можно сказать — блещет изяществом.

    После появления на форме провайдера данных, нужен и потребитель. Не умничая, я добавил простенький код, который просто отображает все посты последовательно.

    1. <asp:Repeater runat="server" ID="repPosts" DataSourceID="dsPosts">
    2.     <HeaderTemplate>
    3.     </HeaderTemplate>
    4.     <ItemTemplate>
    5.       <div>
    6.         <h3>
    7.           <asp:Label ID="lblHeader" runat="server" Text='<%# Eval("Header") %>'></asp:Label>
    8.         </h3>
    9.         <p>
    10.           <asp:Label ID="lblText" runat="server" Text='<%# Helpers.TypographText(Eval("Text").ToString()) %>'></asp:Label>
    11.         </p>
    12.       </div>
    13.     </ItemTemplate>
    14.   </asp:Repeater>
    * This source code was highlighted with Source Code Highlighter.


    И вот тут заканчивается самая простая часть моего повествования. До сих пор, всё что было сделано, можно повторить при помощи мыши. Это было достаточно просто. Мы только что создали объектно-ориентированное представления БД, и используя это представление, начали выводить данные из базы на страницу. При этом, мы ни разу не написали ни одного запроса, не получали данные из базы напрямую, etc…

    Но, что же выводить пользователю, если у нас нет ничего в БД? Нехорошо. Надо написать форму заполнения базы. Теперь мы бросим мышепрограммирование, и займёмся написанием кода.

    Я сделал два самых базовых действия для работы с постами в системе — это добавление и удаление. Сделать редактирование по аналогии с этим кодом не составит труда ни для кого.

    1. namespace DBW
    2. {
    3.   public class Post
    4.   {
    5.     public Post()
    6.     {
    7.  
    8.     }
    9.     public static void New(String PostText, String PostHeader, Int32 UserId)
    10.     {
    11.       DataBaseCore.DbModel m = new DataBaseCore.DbModel();
    12.       DataBaseCore.Post p = new DataBaseCore.Post();
    13.       p.Header = PostHeader;
    14.       p.Text = Helpers.TypographText(PostText);
    15.       p.PublishDate = DateTime.Now;
    16.       p.User = (from usr in m.User where usr.Id == UserId select usr).First();
    17.       m.AddToPost(p);
    18.       m.SaveChanges();
    19.     }
    20.  
    21.     public static void Delete(Int32 PostId)
    22.     {
    23.       DataBaseCore.DbModel m = new DataBaseCore.DbModel();
    24.       DataBaseCore.Post p = new DataBaseCore.Post();
    25.       p = (from pst in m.Post where pst.Id == PostId select pst).First();
    26.       m.DeleteObject(p);
    27.       m.SaveChanges();
    28.     }
    29.   }  
    30. }
    * This source code was highlighted with Source Code Highlighter.


    Казалось бы, всё просто, и да, это так. Но есть пара нюансов.
    Во-первых — это LINQ. Без него в ADO.NET никуда. Так что не стоит отлынивать и вообще забивать на SQL или LINQ, писать запросы всё равно придётся.
    Во-вторых — этот код автоматически генерируется фреймворком, поэтому особого удобства в некоторых моментах ожидать не придётся, и всегда надо быть готовым изменить уже созданный студией код. Например, тут в строке 16 было бы удобнее использовать не объект типа пользователь, который мне пришлось выбирать из БД, а сразу передавать значение идентификатора пользователя. Так было бы удобнее для этого кода, но это не универсально. Поэтому код нуждается в доработке и переосмыслении. Возможно просто надо передавать не идентификатор пользователя, а объект типа пользователь.

    Что дальше? Дальше я буду продолжать писать проект, углубляясь в дебри ADO.NET Entity Framework, и буду с удовольствием делиться своими изысканиями с вами, уважаемые хабраюзеры. Соответственно, будут новые статьи, с более серьёзными и глубокими данными.

    UPD. Тема очень обширная. Здесь не раскрыто и процента возможностей, но продолжение будет 8-)

    Поделиться публикацией

    Похожие публикации

    Комментарии 120

      +2
      Продолжайте, интересно
        0
        Спасибо. Продолжу, конечно.
        На самом деле — все примеры тут с живого сайта, над которым я сейчас работаю. Ещё пара доработок, и я с удовольствием выложу его на всеобщее обозрение.
          +2
          Не плохое введение, технология показалась интересной, но боюсь как и многие другие вещи которые автоматизируют рутинную работу могут показаться неудобными при реализации не совсем стандартных задач. Очень интересно было бы увидеть статью(и) освещающую вопросы типа:
          — Доступ к данным (чтение/создание/удаление/изменение) через хранимые процедуры
          — Работа с сущностями которые в представлении БД имеют составной первичный ключ
          — Работа с деревьями (интересно какую бы реализацию предложил ORM-mapper по-умолчанию),
          — Внесение собственных изменений в сгенерированную модель (в этой статье вы упомянули, что не удобно например при добавлении объекта Post присваивать свойству User экземпляр «пользователя», интересно возможно ли как-нибудь комбинировать оба подхода).
          PS: и сам пойду тоже поищу материал, а то подумаете еще что лентяй и захотел все на блюдечке :)
            –1
            Ладно, так и быть — не подумаю 8-)
            По поводу всех ваших предложений — дествительно всё это актуально, сталкивался не раз с этими проблемами. Просто в моём тестовом проекте я себе этих проблем не создавал 8-) Думаю, можно будет сделать по отдельной статье на каждый из пунктов в вашем комментарии.
              0
              В догонку к предыдущему комментатору, очень хотелось бы услышать о наследовании, которое есть в Entity Framework. Сам на него смотрел, но, если честно, не разобрался, как и на что оно влияет. На диаграмме возможность указать наследование есть, но оно не влияет на код.

              Одно из препятствий, почему я не смог убедить менеджера проекта заюзать эту технологию — разработчик доменной модели посчитал, что без наследования эту штуку использовать накладно. А у меня как-то тяму не хватило с нахрапа взять эту вершину.
        +1
        Угу, помню каких трудов стоило самостоятельно разобраться с LINQ to SQL, с учетом того что всю жизнь писал на C++. Туториалы по ADO.NET EF для начинающих будут как раз кстати. Вобще, хороший пост, все доступным языком расписано.
          0
          А можете пожалуйста объяснить чем это лучше типизированных датасетов и насколько сложно обновлять модель в студии при ее изменении в базе?
            +1
            Ну, сходу что вспомнил:

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

            2) nullable-типы все-таки роднее языку, чем DBNull и дурацкие проверки IsBlaBlaBlaNull()

            3) Вам когда-нибудь приходилось на лету заменять строку подключения или таймаут для команд типизированному датасету? Без рефлекшена затея обречена на провал.
            В EF это можно сделать, вызвав альтернативный конструктор класса.

            P.S. Можно менять модель непосредственно в студии, а модель уж сама внесет нужные изменения в базу. Хотя, верно и обратное.
              +1
              А Вы уверены, что EF поддерживает «ленивую загрузку»? Ссылку в студию. Удивите!

              Насколько я знаю, EF в отличии от LINQ2SQL ленивую загрузку не поддерживает. А разработчики EF обосновывают отсутствие оной необходимостью соответствовать ООП. А именно, при маппинге иерархии классов на таблицы БД, теперь можно приводить сущности к любому из базовых классов, на который есть маппинг.

              И прежде чем воспевать дифирамбы EF проанализируйте производительность DAL, реализованных на ADO.NET, LINQ2SQL, EF, Active Record(NHibernate). Оченьудивитесь.

              И по поводу «менять модель непосредственно в студии». Вы сами-то пробовали так изголяться, или начитались «умных» книжек по EF?
                0
                А можно подробнее про маппинг иерархии классов на таблицы БД? Поясните плиз на простом примере, что вы имеете в виду?
                  0
                  Ну, насколько я понял, у нас есть БД, из неё делается ANEF обёртка. А тут хотят наоборот — изменил что-то в ANEF получил в БД.
                    0
                    Хм. Совсем нет. Как мне кажется, 7y7 разговаривал про отсутствие ленивой загрузки в EF и обосновал ее тем, что к БД предъявляется жесткое требование соответствовать доменной модели. Я бы хотел уточнить момент про приведение мэппингующихся классов, потому что мне непонятно, что к чему приводится.
                      0
                      Суть в том, что приведение к классу наследнику не порождает подчиненных запросов, подтягивающих дополнительные данные. При инстанциации экземпляров сразу используется нужный тип и он заполняется всеми данными. По полиморфизму зачет.
                        0
                        А, понял.
                        Т.е. например, есть класс Car, есть наследник ColoredCar, в наследние дополнительное проперти висит — Color. В таблице у записей соотв. Car поле Color null. Мы загружаем все Car, и EF прочитает все Color, хотя вроде бы и не требовалось. Так?
                          0
                          Если работать с сущностью Car, то EF при загрузке из БД будет обращаться только к тем столбцам, на которые есть маппинг для Car.

                          А если мы загрузили ColoredCar, то эта сущность приводится к базовому классу Car без инициализации дополнительных запросов.

                          А NULL-ы висят в таблице при реализации схемы TPH. Т.к. таблица всего одна, и записи в нее происходят и для сущности Car, и для сущности ColoredCar.
                    0
                    Допустим, есть определенная иерархия классов. Entity Framework позволяет смаппить одну сущность на несколько таблиц. Для реализации наследования используют следующие схемы:

                    Table per Hierarchy. В этом случае вся иерархия помещается в одну таблицу, а поля сущностей маппятся на «свои» колонки таблицы, а в значениях остальных колонок содержится NULL.

                    Table per Type. При такой схеме БД, каждой сущности соответствует своя таблица. Плюсом является то, что БД нормализированная, но отсюда и минус, — при глубокой иерархии будет страдать производительность из-за джоинов.

                    Table per Concrete Type. В этот раз создаются таблицы для каждой ветки иерархии. И каждая таблица будет содержать поля промежуточных базовых сущностей.
                      0
                      О, спасибо!
                      Не совсем понятно, чем иерархия отличается от конкретного типа? И там и там граф объектов ложится в одну таблицу, правильно? Во втором случае мы граф бьем на подграфы, так?
                        0
                        В первом случае будет всего одна таблица (при схеме TPH).
                        В случае TPC таблиц будет столько, сколько и сущностей, не имеющих наследников.

                        Пример: Есть базовый класс «Клиент», у него наследники «Юр. лицо» и «Физ. лицо». В первом случае будет только одна таблица (TPH), во втором случае (TPT) будет три таблица, так сущностей три. А в случае TPC будет две таблица, т.к. конкретных сущностей всего лишь две: «Юр. лицо» и «Физ. лицо».
                    0
                    Поддерживает, правда немного иначе, чем LINQ2SQL. См. метод Load у навигационных свойств.

                    Дифирамбы EF я и не воспевал, просто привел пару плюсов перед типизированными датасетами. Это, скорее, дифирамбы конструктору вижуалстудии, чем самой технологии.

                    На одной маленькой базе пробовал. На сколько-нибудь серьезных вещах — не пробовал. «Умных» книжек не читал вообще.
                  +1
                  Основное приимущество Entity Framework как и других ORM систем над типизированными датасетами — объектный подход к данным (вместо работы с таблицами/колонками/записями вы работаете с сущностями).
                    0
                    Я просто думал, что на Хабре есть подробное описание ANEF, но не нашёл его. Придётся видать ещё и вводную статью делать 8-)
                      0
                      Ну, как раз-таки не все ORM работают именно с сущностями. EF — да, и это одна из положительных фич, мы можем работать с объектами как с сущностями предметной области, не привязываясь изначально к реляционной структуре.
                    +1
                    Вот всегда нравились такие статьи! Во-первых актуально, во-вторых доступно. Автор, с нетерпением будем ждать продолжения.
                      +1
                      Пара замечаний:

                      1) Утверждение "… это LINQ. Без него в ADO.NET никуда" неверно.
                      ADO.NET успешно существовал без LINQ несколько лет, LINQ — это лишь приятное удобство.

                      2) Зачем создавать лишние экземпляры класса? Это я, в частности, про строку 24. Разумеется, в рамках тестовой странички лишний Post — это мелочи, но все же… :)

                      Ну, а в остальном — хорошо, просто, доступно. Пишите еще.
                        0
                        Поддерживаю насчет поправки про LINQ.
                        Однако, LINQ и EF составляют в совокупности гремучую смесь.
                          0
                          Я просто параллельно учу студентов ООП. И от этого привык юзать
                          0
                          Ну и, возможно, есть смысл перенести в .NET?
                            +1
                            Смысл был, а кармы не было 8-)
                            0
                            автор, переносите в .NET
                            один вопрос: поделитесь кодом Helpers.TypographText :)

                            и еще замечание: не понял про какую «следующую версию Visual Studio 2008» идет речь, финальная версия EF доступна в 2008 студии с SP1. Скорее всего статья писалась давно, я не прав?
                              0
                              может автор имел ввиду что в 2010 она доступна из коробки без сп…
                                +3
                                Хаха, вы только не смейтесь, ибо она пока больше заглушка, чем функция. Буду доделывать, и конечно опенсорсить.

                                public static String TypographText(String html)
                                  {
                                    //Regex rDefis = new Regex();
                                    html = html.Replace(System.Environment.NewLine, "<br />");
                                    html = html.Replace("- ", "— ");
                                    html = html.Replace(" -", " —");
                                    
                                    
                                    return html;
                                  }


                                * This source code was highlighted with Source Code Highlighter.

                                  +1
                                  не забудьте еще anti-XSS воткнуть для надежности
                                    0
                                    Да, конечно. Там ещё непочатый край работы.
                                      0
                                      вообще, неплохо бы сделать универсальный .net-типограф и силами хабра отшлифовтаь его до зеркального блеска. предлагаю выложить ваш вариант, когда будет готов, и всем скопом обсудить
                                        0
                                        Да, я этим займусь, ибо пользоваться типографом того самого человека не хочется.
                                          0
                                          Какого «того самого»? А, с другой стороны, почему бы и нет? Есть какие объективные причины?
                                            +1
                                            Ой, я только что на него глянул, и сам обмяк. Я думал, что там нет вэб сервиса, а оказалось есть. Тот самый — это Лебедёвский
                                            Ну, на этом можно и закрывать тему типографа 8-)
                                              0
                                              А, понятно, ну я просто уточнил. Ну да, думаю хороший типограф, если ресурс в интернете, то почему бы не юзать его (если, конечно, нет каких-то действительно объективных «policies» относительно этого).
                                          0
                                          А как мне кажется, лучше было бы не завязываться на одном типографе, а вполне себе нормально будет использовать любой из открытых в вебе, используя в методах типа «TypographText» обращение к этим сервисам.
                                          То есть, я к тому, что зачем изобретать велосипед, когда они и так уже есть, причем достаточно хорошие.
                                            0
                                            не всегда удобно и имеет смысл обращаться к сервисам в интернет
                                            это может быть затратно и в ряде случаев просто неприемлемо
                                              0
                                              Ну я и не спорю. Просто мне показалось, что в общем случае это будет вполне нормально и приемлемо, как, похоже и оказалось :)
                                              0
                                              вот вот 8-) Именно поэтому, мой типограф состоит из трёх строк 8-) Проблему эту решим, не критична щас 8-)

                                              А вот тот факт, что у меня нет работы с юзерами — это неправильно.
                                                0
                                                А про каких юзеров идет речь?
                                                  0
                                                  У меня же вэб проект, и как вы видите у меня есть таблица с пользователями. Но пока у меня нет никакой работы с пользователями. Нельзя даже зарегистрироваться на сайте.
                                                    0
                                                    А, ну так у вас же ASP.NET. Почему бы не использовать целый столп технологий, уже имеющийся у них? В частности, про подсистему Membership'а.
                                                      0
                                                      Признаться честно, я чуть не сблеванул, когда последний раз её юзал. Она не хотели ни в какую вязаться к существующей БД и насрала гавнокодом в БД. Ну, да в общем, я сам тогда был молод и вспыльчив. Щас буду разбираться, поохладив свой пыл 8-)
                                                        0
                                                        Да мы тоже писали свое, свое, но в итоге решили не поддерживать еще один сложный механизм в системах и стали использовать встроенный.

                                                        P.S. Насчет сблевануть — согласен конечно, очень некрасивый он этот механизм и чрезмерно усложненный, но работающий. Тут уже вопрос трудозатрат (т.е. хотите — пишите свое, но проще использовать что есть).
                                              0
                                              Эх… я с октября уже пытаюсь усесться как следует и портировать Jevix, да все никак не подвернется подходящий по размерам сегмент времени.
                                              Пока что в своих проектах использовал утилиту, основанную на регулярках.

                                              Конечно, можно прикрутить типограф «того самого», но он не позволяет резать теги и атрибуты.
                                    0
                                    Эх, я помню, мы начали пробовать EF еще с первой беты (или чего-то там еще, в общем, что первое появилось в сети :).
                                    Самое крутое реально то, что все эти технологии (ASP.NET MVC, EF, VS2008 Express) составляют очень мощный и при этом бесплатный базовый набор для веб-разработчика.
                                      0
                                      Увы, увы, только в рамках парадигмы Майкрософтовского РАДа:) При более серьезной организации хранения данных или же увеличения сложности интеграции (когда данные нужно гонять между несколькими системами), разработанных дизайнером студии классов банально не хватает.
                                        0
                                        Ну дык! Работу по масштабированию, разработке инфраструктуры, оптимизации, виртуализации, кластеризации, интеграции и т. д. никто не отменял :) Я говорил только про базовый инструментарий.
                                          0
                                          Так фишка в том, что EF в таком случае уже не подходит. Имхо, сейчас EF пригоден для быстрого написания приложения, аля code-monkey, взял, натыкал, прибиндил, показал. Для суровых проектов лично я так и не смог разобраться, сможет ли EF удовлетворять предъявляемым требованиям. Скорее нет, чем да:)
                                            0
                                            Я просто за свою карьеру уже понанюхался этих самопальных фреймворков, хочется разобраться с чем-нить типа ANEF. Хотя, я и не думаю, что он универсален.
                                              0
                                              Скажем так, он «имеет свои ограничения» :) Как и любая технология. Но сам EF вполне себе уровня Enterprise. У нас наибольшие тяжбы EF вызвал в unit-тестировании. Там очень много нюансов и надо сначала как следует разобраться, прежде чем создавать mock-объекты сущностей.
                                                0
                                                М:) Можно подробнее? В чем была проблема? Почему интерфейсы не помогли?
                                                  0
                                                  Какие интерфейсы? :)
                                                  Насколько мне известно, ребята из технологического направления в итоге пользовались методом «Test-Specific Subclass» для сущностей Entity Framework'а.
                                                    0
                                                    Понятно:) Жестко и неудобно:)
                                                      0
                                                      Да уж, и ничего не поделаешь :)
                                              0
                                              Ну смотря что значит для суровых проектов.
                                              Меня вот, к примеру, очень даже радует тенденция MS движения в сторону того, что методом «пригоден для быстрого написания приложения, аля code-monkey, взял, натыкал, прибиндил» вполне можно решать задачи enterprise-уровня.
                                                0
                                                Согласен. Но, имхо, самая большая дыра, это отсутствие гибкости. Аналитики легко могут предъявить требования, которые банально могут не вписываться в архитектуру системы, вы не находите?
                                                  0
                                                  Тут вот прикол в том, что единственный аналитик — это я 8-) И бывает так (знаю по собственному опыту), что даже в очень крупной компании зачастую на аналитиков клали с высокой колокольни. Это очень печально, но это факт.
                                                    0
                                                    Во первых, вам повезло:)
                                                    Во вторых, вы не совсем правы. Аналитики, по большему счету, те, которые работают с заказчиком, документы пишут для заказчика. Если обычному программисту дать почитать то, что говорят аналитики, то у него как минимум зашевелятся волосы, ибо реализовать то, что пишут аналитики для заказчика нереально. Но однако, полным виженом системы могут обладать только те, кто общаются с заказчиком и вполне реально, что завтра вот та симпатичная девочка Таня подойдет к тебе и скажет «Илья, а нам нужно чтобы вот эта хренька работала вот так!» И ничего не останется сделать, как утерется:)
                                                      0
                                                      Главное, чтобы делать надо было по-своему. А не так, как тебе сказал аналитик, или ни дай бог заказчик. А то есть некоторые — рассказывать нам, как работать с БД.
                                                        +3
                                                        Стоп стоп стоп. Вы упускаете очень критический момент в разработке. Сделать своему не согласовав решение с аналитиком или с заказчиком — это значит огрести очень большой риск выкинуть то, что сделали. Вы не правы:) По-своему, не значит правильно и уж точно не значит так, как нужно заказчику (в конце концов, он же приемщик и он платит деньги)
                                                          0
                                                          Нет, если аналитик имеет голову на плечах — то его слово — закон. Хоть его можно обжаловать, но в общем — закон. А мне вот, к моему сожалению, не попадалось хороших аналитиков. Ну, просто проекты такие были. И на старых проектаз заказчик не только приносил требования к системе, но и ещё рассказывал нам, как правильно работать с БД на платформе, которой он не знал. Я именно про этот случай.
                                                        0
                                                        Ну так для этого есть ведь и менеджеры проектов :) Они и должны следить за целостностью требований и находить компромиссы (выделено, так как очень важный момент).
                                                          0
                                                          Вы никогда не работали с государственными заказчиками?:) Поверьте, с ними лучше не общаться с точки зрения компромиссов, я молчу про изменяющиеся в ходе разработки требования. Да в вообще говоря, вы про какие компромиссы?:) Легкие хотелки можно отфуболивать, но что касается написанного тз, то тут уж прости-подвинься, но изволь исполнить. Поэтому, имхо, хорошая архитектура, это такая архитектура, которая максимально гибкая. EF, к сожалению, такой гибкости не проявил, очень надеюсь, что пока не проявил и к 2010 студии ее дошлифуют.
                                                            0
                                                            Возможно, надо на реальных примерах смотреть тут уже. Согласен, что EF не идеален, но и не видел, чтобы ставил каких-либо прям совсем уж жестких барьеров. А так — будем надеяться на развитие технологии (я в этом, в принципе, уверен — MS позиционирует его как основной способ доступа к данным в базах для всех новых разработок на .NET и инвестирует достаточно, поэтому технология будет в порядке).
                                                            0
                                                            Задачка. Какое количество менеджеров проекта и аналитиков можно заметить в государственном университете?

                                                            Вариант два: Какое количество менеджеров проекта и аналитиков можно заметить в очень скупой компании? 8-))) Человеческий фактор.
                                                              0
                                                              Может и ни одного. Я рассматриваю общий случай, когда профильная компания занимается масштабным проектом (объем работ, скажем, от 3-х человеко-лет).
                                                        0
                                                        Могут, согласен. Но, во-первых, всегда есть обратная связь с аналитиками и можно попросить их «придумать по-другому», либо, в крайнем случае, искать обходные пути.
                                                        Опять же, по опыту, EF — очень цельная технология, конечно не идеальная, но достаточно удобная и способствует очень быстрой разработке.
                                                        С точки зрения бизнеса, считаю, это тоже нормально — сделать выбор в сторону переписывания некоторых требований к системе, продолжая использовать технологию, которая экономит в итоге кучу времени в разработке и поддержке.
                                                          0
                                                          Выкинуть полностью доменную модель и ОРМ — это не нормально:) Именно это пугает.
                                                            0
                                                            Ну, на практике таких ограничений не встречалось. Там могут быть сложности, но в целом, описать можно все, что можно описать обычным SQL (насколько оптимально — уже дело частного отдельного проекта).
                                                      0
                                                      Перечитал ваши коментарии, так и не понял чего вам не хватает в EF для масштабируемости, распределения, и других ентерпрайс задач.

                                                      Мне кажется то что он генерирует вполне можно допилить ручками до нужных требований. Вы можете привести то чего вам не удалось реализовать? Мне больше из образовательных целей интересно, чем поспорить с вами, только поэтому спришиваю. Ну и может тут коллективно решим :)
                                                        0
                                                        Сейчас перечислю то, шо мне говорил мсье разработчик доменных моделей:
                                                        — Есть табличка Dictionary. Туда надо уложить граф объектов примерно четырех уровней вложенности (класс линейный словарь-класс иерархический словарь-класс словарь с ключем на другую таблицу-специфический класс словарь с ключем на другую таблицу плюс кучка энумов-пропертей в довесок). Я тогда мычал (мычал, потому что специализируюсь в клиентской части), что дескать, наследование есть, но надо в нем разобраться, и т.п. Сейчас те коменты, что выше, дают надежду на решение этой задачки.
                                                        — Задача срезок данных. Требуется загрузить не весь граф объектов целиком, а три связи. Например, ассоциации-ключ ассоциации-тип ключа (линейный словарь). Ну и сюда же до кучи (цитата) «вот возвращает у меня хранимка 5 табличек. Как я объясню EF'у, что у меня именно конкретные объекты переданы, а то и только ченжи».
                                                        — Вон народ выше на лэйзи лоад ругается. Надо мне, предположим, иерархический справочник (возьмем тот же ОКТМО со всеми муниципальными образованиями), пользователю давать открывать в дереве. Ну, я не спорю, можно извернутся и каким-то образом через линк подгружать объекты в дерево, но опять же, это надо пробовать, это надо настаивать что оно будет работать, убеждать и т.п.

                                                        Сами понимаете, как тяжело в наш нынешний век недоверия новым технологиям вводить инновационность:)

                                                0
                                                Спасибо за статью. Хотелось бы почитать о производительности EF в вашем проекте.
                                                  0
                                                  Мой проект — это очень простой сайт. Я пока не делал на нём никаких тестов. Но скоро я закончу с авторизацией, и открою его для всех хабрапользователей, вместе с сорцами. Тогда можно будет устраивать тестирования и DDOSы 8-)
                                                  –3
                                                  «позволяет создавать даталогику вашего проекта в пару кликов мыши» — дельфи стайл? :)
                                                    0
                                                    Почему дельфи стайл? Обычный Rapid Application Developement. Основной конек платформы:)
                                                    +1
                                                    Спасибо, очень доходчиво.
                                                      +1
                                                      Автор! Ты молодец! Немного критики.
                                                      Тематика интересна, но содержимое могло быть и лучше. На будущее, хотелось бы почитать вот о чем (о некоторых пунктах уже говорили):
                                                      — производительность EF vs NHibernate (ActiveRecord) vs true ADO.NET (ага, типизированные датасеты :)
                                                      — примеры хорошей архитектуры с участием EF (насколько я понимаю, вот прям так в конструкторе Поста создавать контекст БД как-то странно для боевых систем, хотя для семплов нормально)
                                                      — использование хранимок, составных ключей
                                                      — изменение модели «руками», перегенерация модели
                                                      — генерация схемы БД по модели (миф или реальность?)

                                                      Для начала хватит.
                                                        0
                                                        Ах да: для того что бы рассказывать про EF, не отвлекаясь на ASP.NET, можно использовать консольное приложение.
                                                        Хотя Entity Data Source — прикольно, да :)
                                                          0
                                                          Ну, на мой взгляд, смысл использовать ANEF в консоли отсутствует. Лучше сразу показывать на живых примерах. Ибо у новичков могут сразу возникнуть вопросы, типа: «зачем всё это вообще надо?». А так — сразу привёл всё к датасорцам, прибиндил, показал.

                                                          Тем более, я на ASP.NET написал приложений раз в 1000 больше, чем для WinForms и Консоли. Мне так удобнее 8-)
                                                          0
                                                          Хехе 8-) Ну, если бы я взялся сразу писать идеальную статью, то она бы была бесконечно длинной: Я бы её никогда не закончил, а вы никогда не прочитали бы 8-)

                                                          Эта статья — лишь маааленький пример. Конечно буду дополнять и расширять.
                                                            0
                                                            +1 к примеру о хорошей архитектуре:) Для двух таблиц выходит складно, но если их десять? Или, даже, так, если есть требование хранить в одной таблице граф объектов?

                                                            Насчет быстродействия можно почитать тут:
                                                            merle-amber.blogspot.com/2008/11/net-orm-2-sql.html
                                                            +1
                                                            Единственный минус EF, который останавливает от продакшн использования это начисто отсутствующая система кеширования, даже стороннего решения найти пока не удалось, если так и дальше будет, то придется прикручивать свое.
                                                              0
                                                              Автору большое спасибо за отличное введение.
                                                              Ждем продолжения.
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                    0
                                                                    пожалуйста
                                                                    0
                                                                    У нас работала такая система, как вы описали. Вся логика имела достаточно простые методы, мы их дописывали, и всё было хорошо. Но потом пришла злая начальница, и сказала, что нам надо всё переделывать, и мы начали перешивать БД. Из 30-40 таблиц она пожирнела до 150, причём все они были жестоко переписаны. На каждую таблицу уходило по 4 маленьких класса, а в итоге, получалось что на выходе мы имели 450-600 классов, каждый из которых был реализован руками. Быстро у нас отпало желание поддерживать такую структуру. Тем более, с тестами всё хорошо, но мы работали по методам EP, на тесты не было времени. (Ну, это уж начальство такое, с ним ничего не поделаешь.) В итоге, там было бы лучше иметь одну самописную систему, в который все ошибки были бы видны, чем писать свою.
                                                                      0
                                                                      Жесть:)
                                                                        0
                                                                        Ещё жёсче было, когда начальница начинала перерисовывать схемы данных. Мы еле удерживали её от этого действа 8-)
                                                                          +1
                                                                          Женщин надо ублажать… иными методами:)
                                                                    0
                                                                    Пара замечаний по коду:
                                                                    1. DataBaseCore.DbModel m = new DataBaseCore.DbModel();
                                                                    Наверное стоит все же засунуть в using

                                                                    2. p.User = (from usr in m.User where usr.Id == UserId select usr).First();
                                                                    лучше заменить на
                                                                    p.User = m.User.SingleorDefault(...);
                                                                      0
                                                                      Спасибо, щас поправлю у себя в коде 8-)
                                                                        0
                                                                        Кстати, я думаю, что DataBaseCore.DbModel m вообще надо вынести в статики, пусть она одна висит постоянно рабочая.
                                                                          0
                                                                          Кстати, просто так, к слову и не в тему:) Один из бичей и багообразующих явлений в asp.net приложении (особенно для тех, кто пришел в asp.net из WinForms), это статики в asp.net. Хорошо работает, когда приложением занят один пользователь, если же пользователей несколько, то статики для них являются объектом синхронизации. Пользователи начинают перехватывать друг у друга команды, мешать использовать транзакции и т.п. Очень весело и пока догонишь, почему глючит, пройдет много времени.
                                                                            0
                                                                            Дада, у нас такое было. Приходится крутиться 8-)
                                                                              0
                                                                              Мы решили проблему тупым инстанциированием и полным отказом от статиков. У вас что-то поинтереснее?
                                                                                0
                                                                                Мы просто сделали так, что для всех однотипных действий был один статик класс. А если вдруг надо было сделать что-то что выбивало этот класс нафиг — можно было создать его инстанс и работать с ним. Например, как было с транзакциями.
                                                                                  0
                                                                                  Простите, а возможны применения технологий многопоточности в асп-нет приложении? Сам я занимаюсь толстыми клиентами, но возможно, скоро придется перпрофилироваться:)
                                                                                    0
                                                                                    Да. Это очень странно и неправильно, но можно 8-).
                                                                                    Именно многопоточность — это достаточно сложно. Но я видел реализации, которые запускали рендеринг объектов, в момент когда пользователю начинала отгружаться страница. И к моменту, когда надо было отдавать отренжереный объект, система уже была готова его отдать. Короче, всё было интересно, но вот я попой чуял, что что-то не очень хорошо.

                                                                                    А вообще — у нас была задача создания чата на основе ASP.NET + JS. Там надо было бороться с потоками.
                                                                                      0
                                                                                      Почему это странно и неправильно???
                                                                                      Смотря какая задача. ASP.NET — это часть .NET, в котором вполне мощный инструментарий для многопоточности. И IIS работает с потоками, используя Thread Pools.
                                                                                        0
                                                                                        Вот и хочу узнать, будет ли у меня, например, работать синхронизированный синглтон (это где в момент гета лочится объект синхронизации) в асп-нет приложении, если приложением будет пользоваться много пользователей?
                                                                                          0
                                                                                          Будет. У нас работает в виде окна чата. И сделать это можно разными способами.
                                                                                            0
                                                                                            Супер, спасибо:)
                                                                                            0
                                                                                            Да, вполне возможно. Как, к примеру в СУБД может лочиться табличка на время вашего действия с базой. База — отдельное приложение. Также можете хостить свой Application-сервер в виде отдельного приложения (в том числе, в отдельном Application Pool на IIS).
                                                                                              0
                                                                                              Поправка — «можете хостить свой синглтон в Application-сервере, работающем в виде консольного приложения, вин-сервиса, IIS-application'а».
                                                                                          0
                                                                                          Впрочем, в рядовом веб-приложении это врядли нужно, конечно. Лучше достигать производительности другими доступными методами, которых великое множество.
                                                                                            0
                                                                                            вот 8-)
                                                                                0
                                                                                Не стоит. MS сама избавляется в новых разработках (таких как ASP.NET MVC) от статиков, имеющих кучу проблем с unit-тестированием. Всегда удобнее модель системы иметь в виде интерфейсов или базовых классов сущностей (ну, это по опыту).
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                    0
                                                                                    А можно тогда уточнить, статик-методы чего использовались?

                                                                                    А я говорил про то, что удобно, когда статик-методов и классов нет у модели приложения, так как при необходимости инстанциировать последнюю для проведения юнит-теста, наталкиваемся на приличный такой болт :) Ибо инстанциировать статик нельзя, задав для него определенные тестовые условия (там какие только мысли не были — вплоть до инстанциирования отдельного application-домена специально для того, чтобы в нем инстанциировались все статики и была уверенность, что никто и ничто эти статики не использует и не изменит).
                                                                                  0
                                                                                  Один коннешн на всех? ну ну %)
                                                                                  Уж сколько раз писали про эти грабли.
                                                                                0
                                                                                Моя ложка дегтя (сужу по проекту на существующей схеме БД):

                                                                                Итак, минусы:
                                                                                — Не умеет работать с датами. совсем.
                                                                                — Хранимые процедуры и функции. Если возникла необходимось добро пожаловать в пользователи библиотеки EFExtensions, позволяющей выполнять голый sql.
                                                                                — Неочевидные баги при смешивании в одном запросе entity sql с linq to sql или query builder methods.
                                                                                — Отвратительный импорт. Во-первых, затирает все изменения, сделанные руками. Во-вторых, views из бд импортируются с проблемами — EF не может корректно указать у них первичный ключ, и в качестве оного берет все столбцы.
                                                                                — Всякие мелочи, вроде остутствия правильного распознавания отношения многие ко многим в случае наличия в таблице-связке отдельного ключа (пример ID-GroupID-ProductID). Приходится заводить отдельную сущность.
                                                                                — Отвратительный xml. При изменении сущности или отношения надо править его в нескольких местах.
                                                                                — Сырость. Документации мало, community пока невелико.

                                                                                Весомых плюсов (по сравнению с nHibernate) не нашел. Из положительного:
                                                                                — Наличие отдельного gui редактора.
                                                                                — Автоматическая генерация моделей. Стоит заметить, что в данном проекте эти модели не использовались за пределами DAL, чтобы была возможность перейти на другие способы получения данных из БД.

                                                                                Итого, я рекомендую для проектов с существующей БД EF не использовать.
                                                                                  0
                                                                                  Спасибо. Хорошая статья.
                                                                                  Сейчас как раз выбираю между Linq2Sql и EF для небольшого проекта.

                                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                  Самое читаемое