powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / Data Access Layer
63 сообщений из 63, показаны все 3 страниц
Data Access Layer
    #34493321
paly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Как организовать? Кто, что использует? Где, что почитать можно? (Windows.Forms)
...
Рейтинг: 0 / 0
Data Access Layer
    #34493334
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Windows Forms разные бывают.
NHibernate в связке со Spring.NET, например.
...
Рейтинг: 0 / 0
Data Access Layer
    #34493423
paly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
а какое отношение к ADO.NET vNEXT? Кто-нибудь пробовал?
...
Рейтинг: 0 / 0
Data Access Layer
    #34493519
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На первый взгляд (судил только по статьям) -- слабее NHibernate в очень многих местах, кроме собственно LINQ.
...
Рейтинг: 0 / 0
Data Access Layer
    #34493536
paly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
тут пишется, что наоборот
...
Рейтинг: 0 / 0
Data Access Layer
    #34493593
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как все печально там. Товарищ что-то загоняется :)
Во-первых, бизнес-классы зачем-то наследуются от System.Data.Objects.Entity
Во-вторых, ниасилил:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
public partial class ProductSubcategory : global::System.Data.Objects.Entity
    {
        /// <summary>
        /// Initialize a new ProductSubcategory object.
        /// </summary>
        public ProductSubcategory()
        {
            // Call DoFinalConstruction if this is the most-derived type.
            if ((((object)(this)).GetType() == typeof(global::AdventureWorksModel.ProductSubcategory)))
            {
                this.DoFinalConstruction();
            }
В третьих, сравнение -- вообще бред сивой кобылы. Чтобы более предметно:
4. Создаем своими руками классы, которые представляют наши бизнес-сущности в базе данных
Совершенно нормальная практика. К тому же, попробуте напялить этот ADO.NET на готовую БД с названиями полей типа _prod_zakaz
Опять же -- для NH есть куча генераторов.
5. Создаем модель данных, указываем Dialect (что сразу привязывает наш готовый ORM к конкретной базе данных и лишает приложение возможности переносимости)
Перемешал мухи с котлетами. Dialect указывается в конфигурационном файле приложения и используется исключительно самим NHibernate'ом. А "модель данных" к нему никак не привязана.
Что получаем в результате:
1. 6 шагов в случае использования ADO.NET Entity Framework против 8 для NHibernate
2. Используем готовые компоненты Microsoft.NET Framework v3.5
И что с того? Вообще к технологиям не относится.
3. Работаем с базой данных с использованием Generics
Начиная с версии 1.2 NHibernate поддерживает их, милости просим.
5. Мы не зависим от базы данных, мы можем изменить провайдера данных, при этом переписывать всю модель не придется (в случае, если структура бд не изменилась), в отличие от NHibernate, где мы четко привязываемся к конкретной БД через dialect.
Ерунда.

Про "сложные каскадные запросы" -- автор, похоже, не работал с HQL ибн Hibernate Query Language.

Поддержка наследования в NH сделана на порядок качественнее.

Сложность в пункте "сделаем сохранение внесенных изменений" -- от незнания предметной области. С теми возможностями, что предоставляет NH наличие трех методов более чем оправдано. В простейшем случае хватает SaveOrUpdate(), да и его вызывать не всегда надо.

Короче говоря, неадекватное сравнение с явным восхвалением ADO.NET vNext
...
Рейтинг: 0 / 0
Data Access Layer
    #34493841
___2222222___
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
palyКак организовать? Кто, что использует? Где, что почитать можно? (Windows.Forms)
DAL в WinForms изначално подразумевается как типизированные объекты доступа к данным (в ADO.NET 2.0).
Типизированные датасеты, таблицы и адаптеры. Студия по одному селекту генерит xsd схему и код к ней. Получается объектная модел сущности в базе. Если нужно дополнить логику отдельного бизнесс объекта, пишешь partial часть класса, который студия сгенерила. Либо можно обернуть эти объекты в свои, чтоб вообще абстрагироваться от понятий объектов в базе и оперировать понятиями предметной области. Это и есть DAL.
...
Рейтинг: 0 / 0
Data Access Layer
    #34494672
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
___2222222___
DAL в WinForms изначално подразумевается как типизированные объекты доступа к данным (в ADO.NET 2.0).
Типизированные датасеты, таблицы и адаптеры.
Это если ну уж совсем по-простому. А там -- чем дальше в лес, тем гуще грабли. Так что забудьте датасеты как страшный сон, мой вам совет.
...
Рейтинг: 0 / 0
Data Access Layer
    #34495023
___2222222___
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Нахлобуч ___2222222___
DAL в WinForms изначално подразумевается как типизированные объекты доступа к данным (в ADO.NET 2.0).
Типизированные датасеты, таблицы и адаптеры.
Это если ну уж совсем по-простому. А там -- чем дальше в лес, тем гуще грабли. Так что забудьте датасеты как страшный сон, мой вам совет.
А что по вашему в типизиранных объектах плохого?
...
Рейтинг: 0 / 0
Data Access Layer
    #34495155
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
___2222222___А что по вашему в типизиранных объектах плохого?
Да нет, я-то обеими руками "за". Но я "за" типизированные объекты Domain Model, а не типизированные датасеты, адаптеры и всем этом зоопарке а-ля Table Module по Фаулеру. Потому как в простых проектах использование датасетов еще может быть оправдано, но чем больше проект, тем тяжелей, неповоротливей и в целом неудобней становится с ними работа.
...
Рейтинг: 0 / 0
Data Access Layer
    #34501090
paly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
есть еще мнения? Кто-нибудь использовал Enterprise Liblary? На сколько там удобно это реализовано?
...
Рейтинг: 0 / 0
Data Access Layer
    #34503486
Sa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нахлобуч
Потому как в простых проектах использование датасетов еще может быть оправдано, но чем больше проект, тем тяжелей, неповоротливей и в целом неудобней становится с ними работа.

+1

paly
Кто-нибудь использовал Enterprise Liblary?

ИМХО в плане ADO.NET ничего интересного.

Код: plaintext
 uid  =  S a

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Data Access Layer
    #34503968
paly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Так какой же наиболее простой в разработке и поддержке путь? Неужели только 3 человека сталкивались с такой проблемой?
...
Рейтинг: 0 / 0
Data Access Layer
    #34503998
Фотография buser
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Sa. А Вы в своих проектах что для постраения DAL/BIZ используете?
Простой путь - разумный компромис... Да, вот ещё один вариантец
...
Рейтинг: 0 / 0
Data Access Layer
    #34504373
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не понятно, что вкладывается в понятие "простой".Если не знаете, что делать - используйте ORM.
На мой взгляд, наиболее оптимальный вариант-CSLA(www.lhotka.net)
...
Рейтинг: 0 / 0
Data Access Layer
    #34507349
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVa
На мой взгляд, наиболее оптимальный вариант-CSLA(www.lhotka.net)
Да уж куда как оптимально. Заведомо тормозной вариант, ибо использует рефлекшн по любому поводу.
...
Рейтинг: 0 / 0
Data Access Layer
    #34508603
paly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Делитесь опытом, комрады! Думаю, что многие сталкиваются с такой проблемой и многим будет интересно, как это делают разработчики с опытом.
...
Рейтинг: 0 / 0
Data Access Layer
    #34508752
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Многое зависит от типа приложения. Я для себя выработал следующую практику, которая, в случае веба и двухзвенки, выглядил примерно следующим образом (использую NHibernate и Spring.NET).
Код разделяется на три слоя -- бизнес-объекты, сервисная логика и слой доступа к данным.
Бизнес-объекты -- это, собственно, объектная модель предметной области. Честная иерархия классов, выполненная без единого гвоздя и в лучших традициях ООП. Например, вот:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
using System;
using System.Collections.Generic;

using octalforty.BizFramework.Core;
using octalforty.BizFramework.Core.Util;

using octalforty.***.ObjectModel.Business.Collections;
using octalforty.***.ObjectModel.Business.Interfaces;

namespace octalforty.***.ObjectModel.Business.Objects
{
    /// <summary>
    /// Represents a weblog.
    /// </summary>
    [Serializable()]
    public class Blog : BusinessObjectWithNameBase, IBusinessObjectWithDescription,
        IBusinessObjectWithKey, IBusinessObjectWithVersionTag
    {
        #region Private Member Variables
        private User owner;
        private String description = String.Empty;
        private String key = String.Empty;
        private Int64 versionTag;
        private IList<BlogPost> posts = new List<BlogPost>();
        #endregion

        #region Protected Properties
        /// <summary>
        /// Gets or sets a reference to the internal collection of blog posts.
        /// </summary>
        protected virtual IList<BlogPost> InternalPosts
        {
            get { return posts; }
            set { posts = value; }
        }
        #endregion

        #region Public Properties
        /// <summary>
        /// Gets or sets a reference to the <see cref="User"/> who is
        /// the owner of this <see cref="Blog"/>.
        /// </summary>
        public virtual User Owner
        {
            get { return owner; }
            set { owner = value; }
        }

        /// <summary>
        /// Gets a reference to the collection of <see cref="BlogPost"/> objects
        /// for the current blog.
        /// </summary>
        /// <remarks>
        /// Blog posts are stored in chronological order with the most recent post
        /// being the last in the collection.
        /// </remarks>
        public virtual BlogPostCollection Posts
        {
            get { return new BlogPostCollection(InternalPosts); }
        }
        #endregion

        /// <summary>
        /// Initializes a new instance of <see cref="Blog"/> class.
        /// </summary>
        public Blog()
        {
        }

        /// <summary>
        /// Adds a post to the <see cref="Posts"/> collection and sets
        /// <see cref="BlogPost.Blog"/> property to reference this page.
        /// </summary>
        /// <param name="post">The post to be added.</param>
        /// <exception cref="ArgumentNullException">
        /// When <paramref name="post"/> is a <see langword="null"/> reference.
        /// </exception>
        public void AddPost(BlogPost post)
        {
            if(post == null)
                throw new ArgumentNullException("post");

            InternalPosts.Add(post);
            post.Blog = this;
        }

        #region IBusinessObjectWithDescription Members
        /// <summary>
        /// Get or sets a description of the object.
        /// </summary>
        public virtual String Description
        {
            get { return description; }
            set { description = NullSafeStringUtil.NullSafeString(value); }
        }
        #endregion

        #region IBusinessObjectWithKey Members
        /// <summary>
        /// Gets or sets a string which is the key of the business object.
        /// </summary>
        public virtual String Key
        {
            get { return key; }
            set { key = NullSafeStringUtil.NullSafeString(value); }
        }
        #endregion

        #region IBusinessObjectWithVersionTag Members
        /// <summary>
        /// Gets or sets business object version tag.
        /// </summary>
        public virtual Int64 VersionTag
        {
            get { return versionTag; }
            set { versionTag = value; }
        }
        #endregion
    }
}

То есть ясно, что, например, владелец блога представлен не свойством типа Int64, в котором содержится идентификатор записи в таблице User, а ссылкой на соответствующий объект.
Дальше -- сервисная логика. Как видно из кода, логики в бизнес-объектах содержится минимум. Вся логика выносится в отдельный слой. Например:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
using System;

using octalforty.BizFramework.Core;

using octalforty.***.ObjectModel.Business.Collections;
using octalforty.***.ObjectModel.Business.Objects;

namespace octalforty.***.Engine.Shared.ComponentModel.Managers
{
    /// <summary>
    /// Defines a contract for the Blog Manager, which is used for managing
    /// database interactions for the <see cref="Blog"/> class.
    /// </summary>
    public interface IBlogManager
    {
        /// <summary>
        /// Returns a collection of <see cref="Blog"/> objects, ordered 
        /// by <see cref="BusinessObjectWithNameBase.Name"/>, ascending.
        /// </summary>
        /// <returns>A collection of <see cref="Blog"/> objects.</returns>
        /// <remarks>
        /// The method is guaranteed not to return <c>null</c>.
        /// </remarks>
        BlogCollection GetBlogs();

        /// <summary>
        /// Returns an instance of <see cref="Blog"/> object with the
        /// <see cref="Blog.Key"/> equal to <paramref name="key"/>.
        /// </summary>
        /// <param name="key"></param>
        /// <returns></returns>
        Blog GetBlogByKey(String key);
    }
}

Да, у меня менеджеры, работающие с БД -- это тоже сервисные классы.
Ну так вот. Есть у нас россыпь сервисных классов. Их мы помещаем в Spring.NET'овский IApplicationContext и либо обеспечиваем к нему единую точку доступа (гуглим по поводу Service Locator), либо (если речь о веб-приложении), в тот же IApplicationContext добавляем еще и все страницы. То есть:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
using System;

using octalforty.***.Engine.Shared.ComponentModel.Managers;

using octalforty.***.ObjectModel.Business.Collections;

namespace octalforty.***.Web.Blogs
{
    /// <summary>
    /// Default octalforty ***Web Blogs page.
    /// </summary>
    public partial class Default : Page
    {
        #region Private Member Variables
        private IBlogManager blogManager;
        private BlogCollection blogs;
        #endregion

        #region Public Properties
        /// <summary>
        /// Gets or sets a reference to the <see cref="IBlogManager"/>.
        /// </summary>
        /// <remarks>
        /// This property is injected by Spring.NET.
        /// </remarks>
        public IBlogManager BlogManager
        {
            get { return blogManager; }
            set { blogManager = value; }
        }
        #endregion

        #region Page Members
        /// <summary>
        /// Initializes data model when the page is first loaded.
        /// </summary>
        /// <remarks>
        /// This method should be overriden by the developer in order to initialize data model for the page.            
        /// </remarks>
        protected override void InitializeModel()
        {
            base.InitializeModel();

            blogs = BlogManager.GetBlogs();
        }

        /// <summary>
        /// Initializes the data bindings.
        /// </summary>
        protected override void InitializeDataBindings()
        {
            base.InitializeDataBindings();
        }

        /// <summary>
        /// Raises InitializeControls event.
        /// </summary>
        /// <param name="e">Event arguments.</param>
        protected override void OnInitializeControls(EventArgs e)
        {
            base.OnInitializeControls(e);

            if(!IsPostBack)
            {
                blogsRepeater.DataSource = blogs;
                blogsRepeater.DataBind();
            } // if
        }
        #endregion
    }
}

(Тут используется встроенная в Spring.NET поддержка ASP.NET). Таким образом, в момент обращения к странице все ссылки на сервисные классы (в данном случае -- ссылка на IBlogManager) уже выставлены Спрингом и всем этим хозяйством можно пользоваться.
Ну а слой доступа к данным -- опять же могучая связка NHibernate + Spring.NET:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
using System;

using NHibernate;

using octalforty.BizFramework.Core;

using octalforty.***.Engine.Shared.ComponentModel.Managers;

using octalforty.***.ObjectModel.Business.Collections;
using octalforty.***.ObjectModel.Business.Objects;

using Spring.Data.NHibernate.Generic;
using Spring.Data.NHibernate.Generic.Support;

namespace octalforty.***.Engine.Core.ComponentModel.Managers
{
    /// <summary>
    /// Implementation of the <see cref="IBlogManager"/> backed up by <see cref="HibernateDaoSupport"/>.
    /// </summary>
    public class BlogManager : HibernateDaoSupport, IBlogManager
    {
        /// <summary>
        /// Initializes a new instance of the <see cref="BlogManager"/> class.
        /// </summary>
        public BlogManager()
        {
        }

        #region IBlogManager Members
        /// <summary>
        /// Returns a collection of <see cref="Blog"/> objects, ordered 
        /// by <see cref="BusinessObjectWithNameBase.Name"/>, ascending.
        /// </summary>
        /// <returns>A collection of <see cref="Blog"/> objects.</returns>
        /// <remarks>
        /// The method is guaranteed not to return <c>null</c>.
        /// </remarks>
        public BlogCollection GetBlogs()
        {
            return new BlogCollection(
                HibernateTemplate.FindByNamedQuery<Blog>("GetBlogs"));
        }

        /// <summary>
        /// Returns an instance of <see cref="Blog"/> object with the
        /// <see cref="Blog.Key"/> equal to <paramref name="key"/>.
        /// </summary>
        /// <param name="key"></param>
        /// <returns></returns>
        public Blog GetBlogByKey(string key)
        {
            return HibernateTemplate.Execute(new HibernateDelegate<Blog>(
                delegate(ISession session)
                {
                    IQuery query = session.GetNamedQuery("GetBlogByKey");

                    HibernateTemplate.PrepareQuery(query);

                    query.SetString("key", key);

                    query.SetMaxResults(1);

                    return query.UniqueResult() as Blog;
                }), true);
        }
        #endregion
    }
}
"Вот в таком вот аксепте" (с)
...
Рейтинг: 0 / 0
Data Access Layer
    #34509511
Фотография Шайтан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
palyесть еще мнения? Кто-нибудь использовал Enterprise Liblary? На сколько там удобно это реализовано?
скорость у этой приблуды сильно хромает ....
там ведь всё на рефлексии, понимаешь
Шайтан
...
Рейтинг: 0 / 0
Data Access Layer
    #34511224
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Осталось еще добавить кучу файлов конфгурации и посмотреть на тот мрак, который твориться с БД, когда на нее напяливают Hibernate. SCSF и WSCF гораздо более вменяемые вещи( с точки зрения наглядности кода и количества затраченных калорий) и с большими возможноcтями, именно благодаря reflection.У любого инструмента есть свои правила применения и если им не следовать, то и будут соответствующие тормоза.
...
Рейтинг: 0 / 0
Data Access Layer
    #34511552
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaОсталось еще добавить кучу файлов конфгурации и посмотреть на тот мрак, который твориться с БД, когда на нее напяливают Hibernate.
А поподробней?
SeVaSCSF и WSCF гораздо более вменяемые вещи( с точки зрения наглядности кода и количества затраченных калорий) и с большими возможноcтями, именно благодаря reflection.У любого инструмента есть свои правила применения и если им не следовать, то и будут соответствующие тормоза.
Если SCSF -- это Smart Client Software Factory, то заявление о наглядности кода (которого там просто таки тьма тьмущая, и бОльшая часть -- именно что работа с reflection) предстает в довольно мрачном свете.
...
Рейтинг: 0 / 0
Data Access Layer
    #34512788
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, в SCSF большая куча кода, но именно это в купе с reflection, позволяет затрачивать минимум калорий при разработке, что на мой вгляд, более существенно, чем подсчет милисекунд.
Например:

[CreateNew]
public MyPresenter Presenter
{
set
{
_presenter = value;
_presenter.View = this;
}
} // при создании View(презантационного слоя) автоматически создается Presenter(обработчик событий)
в свою очередь, в нем на автомате создается сервис

private IMyService _myService = null;

[InjectionConstructor]
public Presenter
(
[ServiceDependency] IMyService MyService
)
{
_myService = MyService;
}

Кратко,внятно и не нужны никакие файлы конфигурации.
Еще пример.Привязка комманды к пункту меню

private void ExtendMenu()
{
ToolStripMenuItem item = new ToolStripMenuItem("My Menu Item");
WorkItem.Parent.UIExtensionSites["Tools"].Add(item);

WorkItem.Commands[CommandNames.ShowMyItem].AddInvoker(item, "Click");
}

Обработчик события

[CommandHandler(CommandNames.ShowMyItem)]
public void MenuToolsMyMenuItem_Click(object sender, EventArgs e)
{
IMyView myView = GetOrCreateWorkItemElement<MyView>("MyView");
WorkItem.Workspaces[Constants.WorkspaceNames.MDIWorkspace].Show(myView);
// сервис и presenter уже создаются на автомате
}

У нас основные 3 вида View используются в 10 модулях практически в 99%.Они создаются только один раз, что резко повышает производительность.
Благодаря reflection просто решается проблема с правами доступа.Грузятся только те модули, на которые есть доступ,автоматически деактивируются комманды, события, визуальные элементы и тд.

Что касается Hibernate, у него тоже есть свои накладные расходы: все тот же reflection, динамическая генерация sql запросов, создание proxy и самое главное-убогая работа с БД.Ручками я заточу запросы гораздо лучше, чем решения на все случаи жизни, это уже проверено.

PS
Все сахера расписывать долго.
PSS
Это моя точка зрения и я не навязываю ее с фанатизмом другим.Везде есть свои плюсы и минусы.
...
Рейтинг: 0 / 0
Data Access Layer
    #34513075
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaЧто касается Hibernate, у него тоже есть свои накладные расходы: все тот же reflection, динамическая генерация sql запросов, создание proxy и самое главное-убогая работа с БД.Ручками я заточу запросы гораздо лучше, чем решения на все случаи жизни, это уже проверено.
Ну что ж вы так. Reflection там уже сто лет как не используется -- вместо этого используются на лету сгенерированные сборки. Т.н. ad-hoc SQL запросы великолепно кэшируются, а то, что там есть какие-то прокси вас ну никак не должно касаться -- их совсем не видно.
Насчет "заточу ручками" -- какие запросы собрались затачивать? INSERT/UPDATE/DELETE ? Или SELECT по PK? Или выборку дочерних записей по FK? Чем же вы лучше напишете, чем NH их сгенерирует?
...
Рейтинг: 0 / 0
Data Access Layer
    #34513306
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все это "великолепие" я видел в реальных проектах,где все несколько сложнее,чем дернуть выборку блогов.Отсюда и стойкое предубеждение.Рассмотрим простой пример, есть счет и его деталировка с десятью записями, сколько запросов к БД сгенерит Hibernate, учитывая все prepare и иже с ними?Как реализована у вас постраничная выборка с произвольным количеством параметров фильтрации?
Как все великолепно кэшируется посмотри кэш запросов.
PS
C reflection все тоже на лету и невидимо, так почему это все так тревожит?
...
Рейтинг: 0 / 0
Data Access Layer
    #34513364
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaРассмотрим простой пример, есть счет и его деталировка с десятью записями, сколько запросов к БД сгенерит Hibernate, учитывая все prepare и иже с ними?
От одного (с джойном) до двух (SELECT счета, SELECT всех его деталировок) :) Как маппинги напишете, так оно и будет.

SeVa
Как реализована у вас постраничная выборка с произвольным количеством параметров фильтрации?
Хотелось бы поподробней про произвольное количество параметров фильтрации. Но на данный момент у нас в память выбираются все идентификаторы требуемых записей, а потом уже бьются на страницы -- решение ПМа. Про встроенную возможность NH по пэйджингу пока ничего сказать не могу.

SeVa
Как все великолепно кэшируется посмотри кэш запросов.
Все запросы, которым ставишь cacheable в true сохраняются в кэше второго уровня. Точнее, сохраняются идентификаторы записей, вернувшихся в результате запроса. Сами записи лежат (или не лежат -- опять же, как маппинги напишете) в том же кэше.

SeVa
PS
C reflection все тоже на лету и невидимо, так почему это все так тревожит?
?
...
Рейтинг: 0 / 0
Data Access Layer
    #34513484
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
То, что одним селектом-это замечательно(Hibernate не стоит на месте).Присовокупим к счету еще оплаты, которые по нему проводились и комментарии(все лежит в отдельных таблицах).В этом случае одним запросом можно будет обойтись?
Под произвольным количеством подразумевается случай, когда необходимо сделать поиск с соединением, скажем таблиц шести, по произвольному набору полей выборки и вернуть только нужную страницу с сортировкой по одному полю.Как в Hibernate будете с этим бороться?
Кэширование упоминалось для ad-hoc запросов на стороне БД.С большим количеством join'ов и параметром это не работает.Парсить запрос и делать генерацию плана выполнения-удовольствие весьма накладное.
Кэшировать данные на стороне клиента не всегда возможно.
То, что Hibernate не поддерживает всех возможностей конкретной БД(туже постраничную выборку), возражений, я думаю, не будет?
...
Рейтинг: 0 / 0
Data Access Layer
    #34513547
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaПрисовокупим к счету еще оплаты, которые по нему проводились и комментарии(все лежит в отдельных таблицах).В этом случае одним запросом можно будет обойтись?
Можно. Только база-то не нагнется :) ?
SeVa
Под произвольным количеством подразумевается случай, когда необходимо сделать поиск с соединением, скажем таблиц шести, по произвольному набору полей выборки и вернуть только нужную страницу с сортировкой по одному полю.Как в Hibernate будете с этим бороться?
Тут либо Criteria API либо ручной HQL/SQL, поскольку серебряной пули нет, как известно.
SeVa
Кэширование упоминалось для ad-hoc запросов на стороне БД.С большим количеством join'ов и параметром это не работает.Парсить запрос и делать генерацию плана выполнения-удовольствие весьма накладное.
Бесспорно. Но ведь и в вашем случае -- в случае рукописных запросов -- БД придется выполнять те же самые действия. Я же имел в виду кэширование текста SQL для ad-hoc запросов внутри самого NH.
SeVa
То, что Hibernate не поддерживает всех возможностей конкретной БД(туже постраничную выборку), возражений, я думаю, не будет?
Всех специфичных возможностей естественно не поддерживает (те же хинты). Про пейджинг не скажу, ибо не пользовался.
...
Рейтинг: 0 / 0
Data Access Layer
    #34513665
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1.База быстрее загнется от кучи мелких запросов.
2.Используются только процедуры с готовыми планами выполнения.

Допускаю, что для блогов с отсутствием бизнес логики, прав доступа и тд, Hibernate-нормальный вариант, как и MySql без транзакций.Но я уже с ним наелся.Вкус и цвет у всех разные, посему на этом точка.
...
Рейтинг: 0 / 0
Data Access Layer
    #34513703
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVa2.Используются только процедуры с готовыми планами выполнения.
Хибернейт и с ними научили работать.
SeVaДопускаю, что для блогов с отсутствием бизнес логики, прав доступа и тд, Hibernate-нормальный вариант, как и MySql без транзакций.Но я уже с ним наелся.Вкус и цвет у всех разные, посему на этом точка.
Перед точкой скажу, что сейчас NH используем в промышленном проекте -- если по количественным характеристикам, то это 130+ классов и 170+ Кб XML'я, их описывающего и больше 350 Кб кода самих бизнес-объектов. БД тоже немаленькая -- в настоящий момент около 120 Гб.
...
Рейтинг: 0 / 0
Data Access Layer
    #34514140
Sa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
buser
А Вы в своих проектах что для постраения DAL/BIZ используете?

Ничего коммерческого или бесплатного.
присматриваюсь к nHibernate, слежу за развитием LINQ.

Код: plaintext
 uid  =  S a

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Data Access Layer
    #34518866
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На досуге решил посмотреть, что нового в Hibernat'e,почитал доки, погуглил и нашел в форуме rsdn такой пост:

NHibernate for .NET - хорошая ORM ?

Так случилось, что для NHibernate тоже приходится писать много своего кода на реальном большом проекте.

V>Если не секрет,
V>подпорки кокого типа вы писали ?

Всего и не упомнишь. Постараюсь вспомнить кое-что:


Свои персистеры.

Свои проперти аксесоры (захотелось использовать generic-коллекции, а NHibernate для 1.1; также иногда хотелось сохранять NULL для default value-type value и т.д.).

Свой кеш-провайдер (захотелось юзать query notifications, а NHibernate ничего про MS SQL Server 2005 не знает).

Код, модифицирующий запросы, генерируемые NHibernate. Иногда приходилось прибегать к "ручному" постпроцессингу сгенерированного запроса в строковом (!) виде, т.к. иначе не получалось.

Код, позволяющий загружать BO, используя свой произвольный SQL и/или хранимые процедуры.

Код, позволяющий выполнять несколько HQL-запросов на чтение в одном database roundtrip.

Свой механизм вызова обработчиков до/после выполнения CRUD-операций — IInterceptor и ILifecycle не подошли потому, что в них или не всё отловишь, или сессию нельзя использовать и т.д.

Больше не помню

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


Их бы усилия да в мирных целях.
На мой взгляд ORM - это непрозрачная стена между разработчиком и БД, посему приходится мастерить стремянки, чтобы через нее перелезть.Для тех, кто девочку с именем БД и в глаза не видел-вполне достойный вариант.Я же с дамами предпочитаю общаться не в электронном виде, а носить их на собственных руках,тогда они более послушные и отзывчивые.
...
Рейтинг: 0 / 0
Data Access Layer
    #34519264
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaНа мой взгляд ORM - это непрозрачная стена между разработчиком и БД, посему приходится мастерить стремянки, чтобы через нее перелезть.Для тех, кто девочку с именем БД и в глаза не видел-вполне достойный вариант.Я же с дамами предпочитаю общаться не в электронном виде, а носить их на собственных руках,тогда они более послушные и отзывчивые.
Вы сами-то пользовались хотя бы одной ORM? Тем же NHibernate?
...
Рейтинг: 0 / 0
Data Access Layer
    #34519567
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, грешен(почти 3 года).Hibernate неплохой продукт, но со своими ограничениями.Меня больше устраивают варианты, где у меня руки ничем не связаны, как в том же CSLA.Есть любители и там, которые с данными работают через Hibernate!!!Полная свобода, вы можете сами выбирать каким образом осуществлять доступ к БД.Hibernate-тоталитаризм.Делаем, как я умею, иначе-расстрел.
Общим строем ходить я никогда не любил.
...
Рейтинг: 0 / 0
Data Access Layer
    #35062046
Фотография webus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaДа, в SCSF большая куча кода, но именно это в купе с reflection, позволяет затрачивать минимум калорий при разработке, что на мой вгляд, более существенно, чем подсчет милисекунд.
Например:

[CreateNew]
public MyPresenter Presenter
{
set
{
_presenter = value;
_presenter.View = this;
}
} // при создании View(презантационного слоя) автоматически создается Presenter(обработчик событий)
в свою очередь, в нем на автомате создается сервис

private IMyService _myService = null;

[InjectionConstructor]
public Presenter
(
[ServiceDependency] IMyService MyService
)
{
_myService = MyService;
}

Кратко,внятно и не нужны никакие файлы конфигурации.
Еще пример.Привязка комманды к пункту меню

private void ExtendMenu()
{
ToolStripMenuItem item = new ToolStripMenuItem("My Menu Item");
WorkItem.Parent.UIExtensionSites["Tools"].Add(item);

WorkItem.Commands[CommandNames.ShowMyItem].AddInvoker(item, "Click");
}

Обработчик события

[CommandHandler(CommandNames.ShowMyItem)]
public void MenuToolsMyMenuItem_Click(object sender, EventArgs e)
{
IMyView myView = GetOrCreateWorkItemElement<MyView>("MyView");
WorkItem.Workspaces[Constants.WorkspaceNames.MDIWorkspace].Show(myView);
// сервис и presenter уже создаются на автомате
}

У нас основные 3 вида View используются в 10 модулях практически в 99%.Они создаются только один раз, что резко повышает производительность.
Благодаря reflection просто решается проблема с правами доступа.Грузятся только те модули, на которые есть доступ,автоматически деактивируются комманды, события, визуальные элементы и тд.

Что касается Hibernate, у него тоже есть свои накладные расходы: все тот же reflection, динамическая генерация sql запросов, создание proxy и самое главное-убогая работа с БД.Ручками я заточу запросы гораздо лучше, чем решения на все случаи жизни, это уже проверено.

PS
Все сахера расписывать долго.
PSS
Это моя точка зрения и я не навязываю ее с фанатизмом другим.Везде есть свои плюсы и минусы.

очень интересна технология SCSF
где про нее почитать подробнее
...
Рейтинг: 0 / 0
Data Access Layer
    #35062235
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Data Access Layer
    #35076459
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Нахлобуч
В CSLA Reflection не "по всякому поводу", а только для MessageRouter-паттерна (DataPortal) в котором 4-5 методов всего лишь.
К тому же ничто не мешает закешировать MethodInfo в какой-либо реализации паттерна Registry, если есть большие опасения по поводу рефлексии, и отдача от этого кеша думаю будет куда лучше чем от кеширования разобранных HQL-запросов в NHibernate.
Я тоже после долгих мытарств в сторону NHibernate, XPO, BLToolkit, пришел к выводу что для меня CSLA это оптимальный вариант. В CSLA в плане полноценного rich-BO layer-a намного больше сделано, хоть и есть несколько мест которые мне мало нравятся.
...
Рейтинг: 0 / 0
Data Access Layer
    #35076473
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ДынникВ CSLA Reflection не "по всякому поводу", а только для MessageRouter-паттерна (DataPortal) в котором 4-5 методов всего лишь.
А так же для заполнения объектов данными, для n-level undo и для кучи остальной требухи.
Роман Дынник
К тому же ничто не мешает закешировать MethodInfo в какой-либо реализации паттерна Registry, если есть большие опасения по поводу рефлексии, и отдача от этого кеша думаю будет куда лучше чем от кеширования разобранных HQL-запросов в NHibernate.
Ну вы и сравнили. Не ясно, во-первых, почему вас так напрягает кэширование HQL'я. Во-вторых, по отдача от кеширования результатов запросов будет настолько значительной, что глядя на все это CSLA будет тихо плакать в сторонке :)
Роман Дынник
Я тоже после долгих мытарств в сторону NHibernate, XPO, BLToolkit, пришел к выводу что для меня CSLA это оптимальный вариант. В CSLA в плане полноценного rich-BO layer-a намного больше сделано, хоть и есть несколько мест которые мне мало нравятся.
"BO-layer" не должен быть rich в том смысле, что там должно быть как можно меньше функционала.
...
Рейтинг: 0 / 0
Data Access Layer
    #35076522
зы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нахлобуч
Во-вторых, по отдача от кеширования результатов запросов будет настолько значительной, что глядя на все это CSLA будет тихо плакать в сторонке :)

хм, наверное поэтому ваш PM, как вы описывали, принял решение оперировать и разбивать на странице списки ID, чтобы таскать данные из кеша? вопрос в том как вы решаете пробелму сортировки и фильтрации по различным полям, ведь кроме ID мало чего известно. Как я понимаю запрос вида select id, value from table where value like '%asd%' hibernate не может предсказать и вынуть из кеша, и полюбому вытянет все из базы?:) кеш хорошо работет в единичных случаях. Если, например, много логики в хранимках, то кеш приходится вырубать.
...
Рейтинг: 0 / 0
Data Access Layer
    #35076573
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
зыхм, наверное поэтому ваш PM, как вы описывали, принял решение оперировать и разбивать на странице списки ID, чтобы таскать данные из кеша?
У нас объемы сравнительно большие -- в среднем по 200К "строк" на запрос, и редкий пользователь просматривает первую тысячу. И поэтому не было смысла выгружать объекты целикомю
зы
вопрос в том как вы решаете пробелму сортировки и фильтрации по различным полям, ведь кроме ID мало чего известно.
Пока никак, но в планах есть. Будем перетряхивать.
зы
Как я понимаю запрос вида select id, value from table where value like '%asd%' hibernate не может предсказать и вынуть из кеша, и полюбому вытянет все из базы?:)
Почему же? Вполне сможет.
зы
кеш хорошо работет в единичных случаях. Если, например, много логики в хранимках, то кеш приходится вырубать.
Ну уж "единичных"... У нас система при упавшей БД работала (не целиком, конечно) около 40 минут только за счет кэша второго уровня.

И вообще -- мы об одном и том же кэше разговариваем?
...
Рейтинг: 0 / 0
Data Access Layer
    #35076663
зы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я уверен да :)
интересен алгоритм хибернейта по предсказанию результатов выборки, при условии, что параметры запроса ранее не встречались.
вообще кеш конечно хорошо, это пожалуй один из немногих весомых плюсов от его монстроидальности.

автор
У нас объемы сравнительно большие -- в среднем по 200К "строк" на запрос, и редкий пользователь просматривает первую тысячу. И поэтому не было смысла выгружать объекты целикомю
не очень понятен смысл вытаскивать 200K строк, если пользователь не смотрит больше 100. В чем тогда фишка не использовать пейджинг скуль сервера? в том, что хибернейт не знает, как это правильно и быстро сделать?
...
Рейтинг: 0 / 0
Data Access Layer
    #35076691
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
зыинтересен алгоритм хибернейта по предсказанию результатов выборки, при условии, что параметры запроса ранее не встречались.
Само собой сам он ничего не гадает. Не было такого набора параметров -- он полезет в БД.
зы
не очень понятен смысл вытаскивать 200K строк, если пользователь не смотрит больше 100.
Это к начальству :) Впечатление производим -- мол, вона сколько у нас найдено...
зы
В чем тогда фишка не использовать пейджинг скуль сервера? в том, что хибернейт не знает, как это правильно и быстро сделать?
Не Хибернейт, а сам сиквель. Он с ума сходит -- в поисковых таблицах меньше 120 миллионов записей редко бывает.
...
Рейтинг: 0 / 0
Data Access Layer
    #35076754
зы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
и сколько памяти отжирает приложение, если не секрет? точнее сколько отжирает кеш второго уровня, если его можно подсчитать отдельно :)
...
Рейтинг: 0 / 0
Data Access Layer
    #35076799
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
зыи сколько памяти отжирает приложение, если не секрет? точнее сколько отжирает кеш второго уровня, если его можно подсчитать отдельно :)
Вот сейчас посмотрел -- самый жирный w3wp.exe на сервере по Task Manager'у занимает 250 Мб. Б о льшая часть -- кеш.
...
Рейтинг: 0 / 0
Data Access Layer
    #35079358
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нахлобуч, при вытягивании 200К записей накладные расходы на reflection тикто и не заметит.
При правильно спроектированной БД, 120м записей для MS SQL - это семечки, если не вытаскивать почти всю БД за раз.
...
Рейтинг: 0 / 0
Data Access Layer
    #35079378
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaНахлобуч, при вытягивании 200К записей накладные расходы на reflection тикто и не заметит.
А нет никакого рефлекшена.
SeVa
При правильно спроектированной БД, 120м записей для MS SQL - это семечки, если не вытаскивать почти всю БД за раз.
120 миллионов -- это в денормализованных поисковых таблицах. При показе данные выгружаются из нормализованных таблиц, причем граф получается довольно развесистый.
...
Рейтинг: 0 / 0
Data Access Layer
    #35079569
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я к тому, что рассуждать о вреде рефлексии при таких выборках, по крайней мере-нелогично.
Накладные расходы на нее в таких случаях ничтожны.
Выводы о том, что CSLA плохо потому,что я так сказал, мало убедительны.
...
Рейтинг: 0 / 0
Data Access Layer
    #35079682
ъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ъ
Гость
НахлобучСамо собой сам он ничего не гадает. Не было такого набора параметров -- он полезет в БД.
а откуда он был, такой набор параметров? юзер не находит что искал и начинает долбить по 2тыс страницам? нахрен нужен такой сервис.
с какой вероятностью попадаете в кеш?
...
Рейтинг: 0 / 0
Data Access Layer
    #35080110
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучНу вы и сравнили. Не ясно, во-первых, почему вас так напрягает кэширование HQL'я. Во-вторых, по отдача от кеширования результатов запросов будет настолько значительной, что глядя на все это CSLA будет тихо плакать в сторонке :)

Как она будет плакать? кешированный HQL можно сравнивать с кешированнием вызовов хп (в CSLA). Так что тут либо никакой разницы, либо CSLA быстрее на этом этапе.
А кеширование MethodInfo (кеширование нескольких делегатов) по механизму быстрее чем разбор и кеширование HQL - выражений.
В CSLA 3.5 рефлексия будет заменена динамическими сборками.

Нахлобуч
"BO-layer" не должен быть rich в том смысле, что там должно быть как можно меньше функционала.
Это спорное филосовское утверждение.
Делаем POCO/POJO - получаем слабосвязанный и легко переносимый (что плюсы), но плохо инкапсулированный код (что несомненно минус) с недостаточным функционалом.
В плане передачи между слоями что POCO, что rich - без разницы - все решается настройкой сериализации.
...
Рейтинг: 0 / 0
Data Access Layer
    #35080118
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кеш-кеш...
сложна реализация не самого кеша (что есть всего лишь IdentityMap+Registry), а управления им - кеширование отдельных классов, время кеширования, память отводимая под кеш и чистка кеша в соответствии с ограничениями, слабые ссылки и т.п.
Я не специалист в NHibernate, поэтому мне интересно как он справляется с этим управлением?
Что имеется ввиду под кешем второго уровня?
Я всегда считал что кеш второго уровня - это UnitOfWork, т.е. по сути дела клиентский кеш в рамках сессии, а кеш первого уровня - это AppServer-кеш.
И по-моему, в этом контексте, сложна реализация именно кеша первого уровня.
...
Рейтинг: 0 / 0
Data Access Layer
    #35080183
зы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Дынник
Я всегда считал что кеш второго уровня - это UnitOfWork, т.е. по сути дела клиентский кеш в рамках сессии, а кеш первого уровня - это AppServer-кеш.
И по-моему, в этом контексте, сложна реализация именно кеша первого уровня.
можно сказать что на самом деле все наоборот
http://www.devx.com/dbzone/Article/29685 (первая ссылка из гугля)
...
Рейтинг: 0 / 0
Data Access Layer
    #35080614
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъа откуда он был, такой набор параметров? юзер не находит что искал и начинает долбить по 2тыс страницам? нахрен нужен такой сервис.
с какой вероятностью попадаете в кеш?
Вы о чем это сейчас?
...
Рейтинг: 0 / 0
Data Access Layer
    #35080625
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaЯ к тому, что рассуждать о вреде рефлексии при таких выборках, по крайней мере-нелогично.
Накладные расходы на нее в таких случаях ничтожны.
Специальный тест писать было лень, поэтому опробовал на том, что есть в текущем проекте. При отключенном Хибернейтовском Reflection Optimizer'е (по сути -- генератор сборок, отвечающих за наполнение объектов данными и их обратный разбор) запрос на 8000+ объектов занимал на 3 секунды больше, чем при включенном оптимизаторе.
...
Рейтинг: 0 / 0
Data Access Layer
    #35080640
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ДынникКак она будет плакать? кешированный HQL можно сравнивать с кешированнием вызовов хп (в CSLA). Так что тут либо никакой разницы, либо CSLA быстрее на этом этапе.
Что такое "кешированние вызовов хп"? Кеширование результатов запросов или чего?
Нахлобуч
А кеширование MethodInfo (кеширование нескольких делегатов) по механизму быстрее чем разбор и кеширование HQL - выражений.

Вот дался вам HQL. Вы думаете, что они при каждом запросе заново парсятся что ли?
Роман Дынник
Это спорное филосовское утверждение.
Делаем POCO/POJO - получаем слабосвязанный и легко переносимый (что плюсы), но плохо инкапсулированный код (что несомненно минус) с недостаточным функционалом.

...который легким движением руки выносится в service layer.
...
Рейтинг: 0 / 0
Data Access Layer
    #35080709
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучЧто такое "кешированние вызовов хп"? Кеширование результатов запросов или чего?

кеширование планов запроса.
Нахлобуч
Вот дался вам HQL. Вы думаете, что они при каждом запросе заново парсятся что ли?

Думаю что сначала ищется в хеш-таблице уже распарсенный. Но в целом, думаю что парсинг достаточно частый из-за множества весьма разношерстных HQL-запросов.
Нахлобуч...который легким движением руки выносится в service layer.
без разницы для service layer чем пользоваться rich или POCO.
Легким движением руки выносится и тот и другой тип.
...
Рейтинг: 0 / 0
Data Access Layer
    #35081623
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
250 Мб/120мил = 2,5байта на запись!!!
...
Рейтинг: 0 / 0
Data Access Layer
    #35081666
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVa250 Мб/120мил = 2,5байта на запись!!!
Вы большой оригинал :) Вот именно эти 120 миллионов в памяти и не хранятся? Там куча справочных данных, профили пользователей и т.д.
...
Рейтинг: 0 / 0
Data Access Layer
    #35081673
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нахлобучхранятся?
Вопросительный знак лишний.
...
Рейтинг: 0 / 0
Data Access Layer
    #35081921
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, нет, Нахлобуч,это Вы большой путанник.Теперь выясняется, что кэшируются только справочники и прочая мелкая лобуда.
...
Рейтинг: 0 / 0
Data Access Layer
    #35081929
зы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мне кажется всем должно быть очевидно, что вся база в кеш не падает, подразумевать это по крайней мере глупо, не так ли?
...
Рейтинг: 0 / 0
Data Access Layer
    #35081956
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaДа, нет, Нахлобуч,это Вы большой путанник.Теперь выясняется, что кэшируются только справочники и прочая мелкая лобуда.
Ну посудите сами -- зачем кэшировать результаты запросов (представляющие из себя россыпь идентификаторов), которые заведомо не будут повторяться? А в кэше лежит отнюдь не мелкая лабуда, поверьте.
...
Рейтинг: 0 / 0
Data Access Layer
    #35082407
ъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ъ
Гость
Нахлобуч зыхм, наверное поэтому ваш PM, как вы описывали, принял решение оперировать и разбивать на странице списки ID, чтобы таскать данные из кеша?
У нас объемы сравнительно большие -- в среднем по 200К "строк" на запрос, и редкий пользователь просматривает первую тысячу. И поэтому не было смысла выгружать объекты целикомю
Нахлобуч зы
В чем тогда фишка не использовать пейджинг скуль сервера? в том, что хибернейт не знает, как это правильно и быстро сделать?
Не Хибернейт, а сам сиквель. Он с ума сходит -- в поисковых таблицах меньше 120 миллионов записей редко бывает.
НахлобучВы о чем это сейчас?
Так в чем фишка не использовать пейджинг скуль сервера?

НахлобучТам куча справочных данных, профили пользователей и т.д.
У всех к кеше куча справочных данных и профили пользователей.
"и т.д." показывай?
...
Рейтинг: 0 / 0
Data Access Layer
    #35082444
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъТак в чем фишка не использовать пейджинг скуль сервера?
В том, что он захлебывается. Пробовали уже.

ъ
У всех к кеше куча справочных данных и профили пользователей.
"и т.д." показывай?
Охх...

Туристический сервер. Поиск и бронирование туров. Загружаем данные, кладем в свою БД. Денормализуем на отдельный сервер, на нем ищем. При выводе из основного сервера читается информация о городах (несколько тысяч), странах (около 200 штук, по-моему), отелях (30+ тысяч, с фотографиями и прочим барахлом), типах питания, звезностях, категориях номеров (все от десятков до сотен единиц). При бронировании вытягиваются данные о туристах, сервисах бронирования, транспортах и прочем.
...
Рейтинг: 0 / 0
Data Access Layer
    #35082489
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вам просто нужен вменяемый базаданщик и тогда ничего захлебываться не будет.
...
Рейтинг: 0 / 0
63 сообщений из 63, показаны все 3 страниц
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / Data Access Layer
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]