Здравствуйте, gandjustas, Вы писали:
G>Алан Кей и Бертран Мейер как раз в своих определениях ООП опираются на побочные эффекты при взаимодействии с объектами.
Извините, но резануло глаз. Алане Кей опр. ООП как возможность отправки сообщений объектам -- на это можно, конечно, натянуть побочные эффекты. Мейер в определении ООП вообще побочные эффекты не упоминает.
Мартин или кто-то подобный говорил, что побочные эффекты -- это то, ради чего происходит вычисление.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Алан Кей и Бертран Мейер как раз в своих определениях ООП опираются на побочные эффекты при взаимодействии с объектами.
S>Извините, но резануло глаз. Алане Кей опр. ООП как возможность отправки сообщений объектам -- на это можно, конечно, натянуть побочные эффекты. Мейер в определении ООП вообще побочные эффекты не упоминает.
Кей говорил что объекты общаются посредством отправки сообщений.
Мейер прямо говорит, что объекты — данные+методы, а также инкапсуляция+полиморфизм+наследоание.
Какое из этих определений осмысленно, если мы исключаем побочные эффекты от методов или сообщений?
S>Мартин или кто-то подобный говорил, что побочные эффекты -- это то, ради чего происходит вычисление.
Я знаю, что побочные эффекты — то, ради чего происходит вычисление. Но это вовсе не означает, что надо при проектировании опираться на побочные эффекты. На практике как раз проще делать чистые функции, а побочные эффекты изолировать. Но это по ФП, а не ООП.
S>>Извините, но резануло глаз. Алане Кей опр. ООП как возможность отправки сообщений объектам -- на это можно, конечно, натянуть побочные эффекты. Мейер в определении ООП вообще побочные эффекты не упоминает.
G>Кей говорил что объекты общаются посредством отправки сообщений. G>Мейер прямо говорит, что объекты — данные+методы, а также инкапсуляция+полиморфизм+наследоание.
Не-а, он(Мейер) говорил про абстрактные типы данных, как важнейшую черту ООП. "данные+методы" сильно ниже.
G>Какое из этих определений осмысленно, если мы исключаем побочные эффекты от методов или сообщений?
Справедливое замечание, но вообще-то любое определение осмысленно, поскольку речь идет о другом способе размышлений над побочными эффектами, на другом уровне абстракции. Т.е. они где-то присутствуют (в методах, вестимо), но не это уже главное.
G>опираться на побочные эффекты.
Здравствуйте, IT, Вы писали:
IT>>>Потому что в последние лет 8 появились более продвинутые способы работы с БД. B>>А можно более развернуто? Какие?
IT>Большие дяди в последнее время используют исключительно LINQ.
Дык, а если в базе больше сотни таблиц и несколько сотен хранимок, функций и другого барахла? ИМХО проще чутка подрехтовать интерфейс топикстартера и получить сверхтонкий "репозиторий" поверх линка, тупо для удобства работы.
interface IRepository<T> where T : class
{
ListIQueryable<T> All { get; private set; };
T Find(int entityId);T SaveOrUpdate(T entity);
T Add(T entity);
T Update(T entity);
void Delete(T entity);
}
В таком случае все эти SP ушли бы в соответствующие репозитории(для совместимости) и их можно было спокойно переделывать в нормальные шарповые функции, оставляя SP только там где реально нужно. Плюс будет место для общей логики.
Здравствуйте, Baudolino, Вы писали:
B>Задача любого архитектурного паттерна — фрагментация сложности.
При условии, что архитектурные решения не вносят ещё больше проблем, чем решают.
B>Паттерны DAL отделяют сложность бизнес-логики от сложности работы с хранилищем данных с помощью разного вида интерфейсов.
Не совсем так. DAL изолирует работу с базой в терминах самой базы от остальной части приложения путём конвертации терминов приложения в термины БД и наоборот.
С этим гораздо лучше справляется LINQ.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, __SPIRIT__, Вы писали:
IT>>Большие дяди в последнее время используют исключительно LINQ.
__S>Дык, а если в базе больше сотни таблиц и несколько сотен хранимок, функций и другого барахла?
От хранимок нужно избавлятся при первом удобном случае. Логика в БД — это сегодня нонсенс. Что касается сотен всякого барахла, то не вижу никаких проблем. По таблицам генерируется модель данных приложения, которая кстати, может включать и функции и сохранённые процедуры.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Большие дяди в последнее время используют исключительно LINQ.
__S>>Дык, а если в базе больше сотни таблиц и несколько сотен хранимок, функций и другого барахла?
IT>От хранимок нужно избавлятся при первом удобном случае.
Так то оно так, но процесс весьма растянут во времени...
IT>Логика в БД — это сегодня нонсенс. Что касается сотен всякого барахла, то не вижу никаких проблем. По таблицам генерируется модель данных приложения, которая кстати, может включать и функции и сохранённые процедуры.
да но если это все запихнуть в один дб контекст, там ничерта не найти будет. Намного удобнее, раскидать их по "репозиториям"
Здравствуйте, __SPIRIT__, Вы писали:
IT>>От хранимок нужно избавлятся при первом удобном случае. __S>Так то оно так, но процесс весьма растянут во времени...
Именно поэтому рулит linq2db, т.к. совершенно не навязывает своей архитектуры и можно всё начинать использовать в паралель.
__S>да но если это все запихнуть в один дб контекст, там ничерта не найти будет. Намного удобнее, раскидать их по "репозиториям"
Используйте схемы. linq2db для схем генерирует отдельные классы. Например, если таблица Issuer находится в схеме Instrument, то обращение к ней будет
db.Instrument.Issuers
Очень удобно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Используйте схемы. linq2db для схем генерирует отдельные классы. Например, если таблица Issuer находится в схеме Instrument, то обращение к ней будет
IT>
Вопрос относительно терминологии. Как вы назовете объект, который будет связывать в единую конфигурацию такие вещи, как кеш, аудит доступка к данным, сам доступ к данным и что-нибудь еще? При этом я хочу менять способ доступа к данным, оставляя все остальное.
Здравствуйте, another_coder, Вы писали:
_>Вопрос относительно терминологии. Как вы назовете объект, который будет связывать в единую конфигурацию такие вещи, как кеш, аудит доступка к данным, сам доступ к данным и что-нибудь еще?
Я бы такую штуку назвал помойкой.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, another_coder, Вы писали:
_>Здравствуйте, IT.
_>Вопрос относительно терминологии. Как вы назовете объект, который будет связывать в единую конфигурацию такие вещи, как кеш, аудит доступка к данным, сам доступ к данным и что-нибудь еще? При этом я хочу менять способ доступа к данным, оставляя все остальное.
Не знаю как у тебя, а у меня эти функции выполняет Entity Framework. Он умеет логировать запросы, сохраняет в памяти запрошенные объекты и собственно получает данные.
Ты все-таки потрудись привести сценарий, когда и чего нужно менять в доступе к данным и какие для этого абстракции ты создашь. Иначе получается сферический конь.
Здравствуйте, another_coder, Вы писали:
_>Тем не менее, она есть в каждом проекте. Опишите, как вы все это объединяете в одном проекте? Если у вас был опыт, конечно.
Опыт если когда-то и был, то я уже не помню.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas.
G>Не знаю как у тебя, а у меня эти функции выполняет Entity Framework. Он умеет логировать запросы, сохраняет в памяти запрошенные объекты и собственно получает данные.
G>Ты все-таки потрудись привести сценарий, когда и чего нужно менять в доступе к данным и какие для этого абстракции ты создашь. Иначе получается сферический конь.
Это хорошо, но если так получилось что проект писали те, кто не знает, как EF все это делает, или когда его еще не было, то, вполне возможно, они захотят ручками это все реализовать. Например, старинный проект, где все было написано на ADO.NET, а теперь решили переехать на EF. Сразу все переписать — нереально. Получается поэтапный переезд с выделением одного, другого. Появляется сначала, как бы, два репозитория, которые выполняют разные вещи: 1) реализует всю кухню по созданию бизнесс объектов (начальные условия выборок, системные фильтры, если нет в хранимках и пр)
2) реализует сам доступ к данным с помощью либо ADO.NET, либо EF.
Тут получается неоднозначная ситуация: два объекта, с разным назначением, описываются одним и тем же термином, по классическому определению: оба оперируют списками объектов. Но по факту у объектов разные цели.
Получилось мне описать ситуацию, чтобы она не была похожа на коня в вакууме?
Ну вот еще один пример о том же, но с другой стороны. Например, делался стартап. DAL написали по фаулеру, создали репозиторий, как в самом начале. С ростом проекта решили, что надо поддерживать разные базы (классика!), но BLL и DAL то уже написаны и это не переписать за неделю. <долгий рассказ о детялх>. Поэтому выделили в DAL провайдер данных из репозитория. По сути выделили один объект из другого, у которых практически идентичный CRUD интерфейс. Только прошлый стал как бы более умным и его дергают объекты BLL, а он дергает новый "репозиторий". И тут снова ситуация, когда новый человек в проекте может спросить: "нафига вам два репозитория? что за булшит?"
Можно предположить, что второй объект это не репозиторий, а DAO. А вот первый — репозиторий. Если так, то до момента изменения архитектуры никакого репозитория не было. Иначе, получается, что термин репозиторий сначала обозначал одно, потом другое. Собственно, этот момент мне и не нравится. Я считаю, что термин должен однозначно описывать то, что за ним скрывается. Например, при старте проекта так и называть: мы создаем DAO. Тогда акценты сразу правильно будут расставляться и говны в коде будет поменьше. Ведь никто не захочет в DAO запихивать еще и джойны и пр, как мне кажется.
Как у вас получается различать объекты в похожей ситуации?
Здравствуйте, another_coder, Вы писали:
_>Здравствуйте, gandjustas.
G>>Не знаю как у тебя, а у меня эти функции выполняет Entity Framework. Он умеет логировать запросы, сохраняет в памяти запрошенные объекты и собственно получает данные.
G>>Ты все-таки потрудись привести сценарий, когда и чего нужно менять в доступе к данным и какие для этого абстракции ты создашь. Иначе получается сферический конь.
_>Это хорошо, но если так получилось что проект писали те, кто не знает, как EF все это делает, или когда его еще не было, то, вполне возможно, они захотят ручками это все реализовать.
Я писал проект на делфи в 2005 году и делал свой orm, у меня там было и логирование запросов и identity map для кеша объектов. Там был реализован паттерн repository точно как описал фаулер. Но ни одного класса с таким именем не было.
Сегодня вообще нет необходимости писать полностью доступ к данным, а не использовать ef\linq2db\hibernate.
_>Например, старинный проект, где все было написано на ADO.NET, а теперь решили переехать на EF. Сразу все переписать — нереально. Получается поэтапный переезд с выделением одного, другого. Появляется сначала, как бы, два репозитория, которые выполняют разные вещи:
А с чего ты взял что репозитарий там был? Мания везде тулить репозитарии появилась относительно недавно. И уже сильно после того, как появились ORM.
Но даже если предположить, что бы, то зачем делать два — неясно совершенно.
1) Для начала надо заменить ручной маппинг и DbCommand на linq2db
2) Потом текстовые запросы\хранимки переписать на Linq
3) Потом прокинуть IQueryable выше по стеку вызовов и сократить количество методов в dal
Если что — я уже так делал на одном проекте.
_>Тут получается неоднозначная ситуация: два объекта, с разным назначением, описываются одним и тем же термином, по классическому определению: оба оперируют списками объектов. Но по факту у объектов разные цели.
Никаких двух не будет.
Я уже понял что наличие repository обосновывается только желанием делать repository. Никаких объективных причин пилить их нету.
_>Получилось мне описать ситуацию, чтобы она не была похожа на коня в вакууме?
Пока нет.
Так и не увидел необходимости иметь два разных метода доступа к одним и тем же данным. Так и не увидел потребности вручную реализовывать паттерн repository.
_>Ну вот еще один пример о том же, но с другой стороны. Например, делался стартап. DAL написали по фаулеру, создали репозиторий, как в самом начале. С ростом проекта решили, что надо поддерживать разные базы (классика!), но BLL и DAL то уже написаны и это не переписать за неделю. <долгий рассказ о детялх>. Поэтому выделили в DAL провайдер данных из репозитория. По сути выделили один объект из другого, у которых практически идентичный CRUD интерфейс. Только прошлый стал как бы более умным и его дергают объекты BLL, а он дергает новый "репозиторий". И тут снова ситуация, когда новый человек в проекте может спросить: "нафига вам два репозитория? что за булшит?"
Процитирую себя
Я уже понял что наличие repository обосновывается только желанием делать repository. Никаких объективных причин пилить их нету.
_>Как у вас получается различать объекты в похожей ситуации?
Никак, я сотру нафиг это говно. код доступа к данным, у которого в баз 10 табличек (стартап же) переписывается на ORM за полдня.
Здравствуйте, another_coder, Вы писали:
_>Здравствуйте, IT.
_>Вопрос относительно терминологии. Как вы назовете объект, который будет связывать в единую конфигурацию такие вещи, как кеш, аудит доступка к данным, сам доступ к данным и что-нибудь еще? При этом я хочу менять способ доступа к данным, оставляя все остальное.
Связыванием занимается обычно контейнер DI, на основе конфигурации. Конкретные задачи кэширования и аудита можно решать декларативно через AOP, тогда у вас реализация доступа к данным от них зависеть не будет, и ее будет проще изменить. Пример изменения: почитав восторженные отзывы технохипстеров, попробовали какую-нибудь MongoDB, не понравилось, переехали в старый добрый Postgres. Меняется только конфигурация DI и реализация работы с хранилищем в DAO (ODM -> ORM). DI как навешивал, используя паттерн Proxy, журналирование и кэширование результатов вызовов методов DAO, так и навешивает — ему пофиг, что там внутри. Потом, конечно, надо будет посмотреть, как система ведёт себя в разных профилях нагрузки, но там доработки будут точечными.
Здравствуйте, IT, Вы писали:
IT>У нас класс так называется только потому что как-то не придумалось другого названия. Но с предложенным интерфейсом репозитория он не имеет ничего общего. Во-первых, у нас вообще нет никакого интерфейса, потому что он нафиг не нужен. Во-вторых, основная задача нашего класса — возможность тестирования процессов, которые его используют без чтения данных из базы. Т.е. это ближе к DI, чем к паттерну Repository. А здесь репозиторий нужен как часть или даже замена DAO, такой классический пережиток тяжелого прошлого.
А не могли бы вы приблизительную сигнатуру вашего класса показать? Так чтобы точно понимать...
Если нам не помогут, то мы тоже никого не пощадим.
