Моделирование перекрестных соединений контекста - LINQ/C#
Были исследования (a) sup>, которые показывают, что стоимость исправления ошибки становится выше, когда вы уходите от точки, где ошибка была введена.
Например, как правило, исправление ошибки в программном обеспечении, которое вы еще даже не добавили в систему контроля версий, будет относительно недорогим. Я настаиваю на том, что это ваше время и не так много (если вы хорошо справляетесь с работой).
Сравните это с тем, сколько стоит исправить, когда клиент (или все ваши клиенты) обнаружат эту проблему. Вовлекается много людей, и нужно спешно создавать новое программное обеспечение и выдвигать его на поле.
1110 Это крайнее сравнение. Но даже разница между модульными и интеграционными тестами может быть очевидна. Код, который не проходит модульное тестирование, в основном затрагивает только одного разработчика (если, конечно, его не ждут другие разработчики / тестировщики / и т.д.). Однако, как только ваш код включается в интеграционное тестирование, дефект может начать задерживать других человек в вашей команде.
Мы не мечтали бы заменить наши модульные тесты интеграционными тестами, поскольку:
- Наши модульные тесты также автоматизированы, поэтому, помимо начальной настройки, стоимость их выполнения невелика .
- Они формируют начало интеграционных испытаний. Все модульные тесты перезапускаются на этапе интеграции, чтобы проверить, что сама интеграция ничего не сломала, и , затем есть дополнительные тесты, которые были добавлены командой интеграции.
(a) sup> См., Например, http://slideshare.net/Vamsipothuri/defect-prevention , слайд № 5 или поиск сеть для Defect prevention : Reducing costs and enhancing quality.
3 ответа
Может быть, что-то вроде этого поможет вам начать в правильном направлении. Я создал фиктивную базу данных с похожими столбцами на основе ваших имен столбцов и получил некоторые результаты.
class Program
{
static AccountContextDataContext aContext = new AccountContextDataContext(@"Data Source=;Initial Catalog=;Integrated Security=True");
static LoanContextDataContext lContext = new LoanContextDataContext(@"Data Source=;Initial Catalog=;Integrated Security=True");
static void Main()
{
var query = from a in aContext.ACCOUNTs
join app in aContext.APPLICATIONs on a.GUID_ACCOUNT_ID equals app.GUID_ACCOUNT
where app.GUID_APPLICATION.ToString() == "24551D72-D4C2-428B-84BA-5837A25D8CF6"
select GetLoans(app.GUID_APPLICATION);
IEnumerable<LOAN> loan = query.First();
foreach (LOAN enumerable in loan)
{
Console.WriteLine(enumerable.GUID_LOAN);
}
Console.ReadLine();
}
private static IEnumerable<LOAN> GetLoans(Guid applicationGuid)
{
return (from l in lContext.LOANs where l.GUID_APPLICATION == applicationGuid select l).AsQueryable();
}
}
Надеюсь, это поможет!
Это "обходной путь", который мы нашли ...
Мы создали наши таблицы из другой базы данных вручную, и если она находится на том же сервере, мы добавили к таблице префикс имя с помощью:
<DatabaseName>.<SchemaName>.<YourTableName>
, если они находятся на связанном сервере, вы должны также добавить к нему префикс с именем сервера:
<ServerName>.<DatabaseName>.<SchemaName>.<YourTableName>
Это позволит вам выполнять соединения и по-прежнему возвращать невыполненный IQueryable ... что мы разыскивается. Два других способа включают присоединение к IEnumerables в памяти, что означает, что вы извлекаете все записи для каждого, прежде чем выполнять соединение (см. Выше) и выполнять соединение IQueryable с использованием метода contains, который имеет ограничения ...
Надеюсь, в будущем DataContext будут построены достаточно умно, чтобы знать, что если серверы связаны, вы можете выполнять соединения между двумя разными серверами.
Я предпочитаю создать отдельный контекст данных, содержащий только две таблицы, которые вы хотите объединить. Но я полагаю, что вы могли бы поддерживать временную таблицу (содержащую данные из первого контекста) во втором контексте, а затем присоединяться к временной таблице.