Несколько классов DataContext когда-либо уместны?

Question

Несколько классов DataContext когда-либо уместны?

Изменение кода для поиска без учета регистра с использованием запроса LIKE вместо нахождения точных совпадений ...

DECLARE
  match_count INTEGER;
  -- Type the owner of the tables you want to search.
  v_owner VARCHAR2(255) :='USER';
  -- Type the data type you're looking for (in CAPS). Examples include: VARCHAR2, NUMBER, etc.
  v_data_type VARCHAR2(255) :='VARCHAR2';
  -- Type the string you are looking for.
  v_search_string VARCHAR2(4000) :='Test';
BEGIN
  dbms_output.put_line( 'Starting the search...' );
  FOR t IN (SELECT table_name, column_name FROM all_tab_cols where owner=v_owner and data_type = v_data_type) LOOP
    EXECUTE IMMEDIATE 
    'SELECT COUNT(*) FROM '||t.table_name||' WHERE LOWER('||t.column_name||') LIKE :1'
    INTO match_count
    USING LOWER('%'||v_search_string||'%');
    IF match_count > 0 THEN
      dbms_output.put_line( t.table_name ||' '||t.column_name||' '||match_count );
    END IF;
  END LOOP;
END;

30

asp.net .net linq-to-sql datacontext

задан Jarrod Dixon 22 March 2012 в 00:01

4 ответа

По моему опыту, с LINQ к SQL и LINQ к Объектам DataContext синонимичен с соединением с базой данных. Таким образом, если бы необходимо было использовать несколько хранилищ данных, то необходимо было бы использовать несколько DataContexts. Моя реакция пищеварительного тракта - Вы, не заметил бы к большой части замедления с DataContext, который охватывает большое количество таблиц. Если бы Вы сделали однако, то Вы могли бы всегда разделять базу данных логически в точках, где можно изолировать таблицы, которые не имеют никаких отношений к другим наборам таблиц и создают несколько контекстов.

2

ответ дан John Downey 22 March 2012 в 00:01

1

При переименовании .template к работам GITGUI_MSG с мерзавцем gui, поскольку @johnny прокомментировал для другого ответа. – egbit 26 May 2019 в 00:54

Я пререкался по тому же вопросу пока ретро, соответствующее LINQ к SQL по DB прежней версии. Наша база данных является чем-то вроде громадины (150 таблиц) и после некоторого размышления и экспериментирования, я выбрал использовать несколько DataContexts. Рассматривают ли это, антишаблон еще неизвестно, но на данный момент он делает жизнь управляемой.

5

ответ дан Kev 22 March 2012 в 00:01

1

Отредактированный для отражения этого. Спасибо. – MatrixFrog 19 September 2010 в 06:27

Я думаю, что John корректен.

"Мое основное беспокойство, которое инстанцирует и располагает один огромный класс DataContext все время для отдельных операций, которые касаются определенных областей Базы данных, было бы, налагают ненужное наложение на ресурсы приложений"

, Как Вы поддерживаете тот оператор? Каков Ваш эксперимент, который показывает, что крупный DataContext является узким местом производительности? Наличие нескольких datacontexts много похоже на наличие нескольких баз данных и не имеет смысл в подобных сценариях, то есть, почти никогда. Если Вы работаете с несколькими datacontexts, необходимо отслеживать, которых принадлежат объекты, с которым datacontext и Вы не можете связать объекты, которые не находятся в том же контексте данных. Это - дорогостоящий запах дизайна ни для какой реальной выгоды.

@Evan "DataContext (или Linq к Объектам ObjectContext) является большим количеством "единицы работы", чем соединение", Которое является точно, почему у Вас не должно быть больше чем одного datacontext. Почему Вы хотели бы больше что одна "единица работы" за один раз?

4

ответ дан liammclennan 22 March 2012 в 00:01

1

git gui часть комплекта мерзавца, таким образом it' s доступный всему мерзавцу платформ доступно. – fuz 19 September 2010 в 03:39

Другие вопросы по тегам:

asp.net .net linq-to-sql datacontext

Похожие вопросы:

При переименовании .template к работам GITGUI_MSG с мерзавцем gui, поскольку @johnny прокомментировал для другого ответа. — egbit, 26 May 2019 в 00:54
Отредактированный для отражения этого. Спасибо. — MatrixFrog, 19 September 2010 в 06:27
git gui часть комплекта мерзавца, таким образом it' s доступный всему мерзавцу платформ доступно. — fuz, 19 September 2010 в 03:39

score 27 · Accepted Answer

Я не соглашаюсь с ответом John's. DataContext (или Linq к Объектам ObjectContext) является большим количеством "единицы работы", чем соединение. Это справляется с отслеживанием изменений, и т.д. Посмотрите это сообщение в блоге для описания:

Время жизни LINQ к SQL DataContext

четыре основных момента этого сообщения в блоге то, что DataContext:

идеально Подходит для подхода "единицы работы"
, также разработан для эксплуатации сервера "не сохраняющей состояние"
, не разработан для Долговечного использования

Should be used very carefully after
any SumbitChanges() operation.

по этой причине, я не думаю с помощью больше чем одного DataContext, делал бы что-то плохое - на самом деле, создавание различного DataContexts для различных типов работы поможет сделать LinqToSql impelmentation более usuable и организованным. Единственный недостаток - Вы, не был бы в состоянии использовать sqlmetal, чтобы автоматически сгенерировать Ваш dmbl.

git gui, по крайней мере, в версии 0.13 как часть мерзавца 1.7.4.msysgit.0, сохраняет сообщение о фиксации в .git/GITGUI_MSG между фиксациями, таким образом, Вы don' t даже должен оставить его открытым, в то время как Вы работаете..., Вы могли даже использовать тот файл в качестве своего временного местоположения редактирования - тот путь при использовании GUI you' ll имеют Ваши примечания и если Вы фиксируете из командной строки, Вы просто используете-t .git/GITGUI_MSG... — johnny, 16 August 2011 в 17:56