Я должен использовать один LINQ DataContext или многих?
Это должно сделать это.
function getFrequency(string) {
var freq = {};
for (var i=0; i<string.length;i++) {
var character = string.charAt(i);
if (freq[character]) {
freq[character]++;
} else {
freq[character] = 1;
}
}
return freq;
};
document.getElementById('myButton').onclick = function(){
var str = document.getElementById('text').value;
var result = getFrequency(str);
document.getElementById('result').value = JSON.stringify(result);
}<textarea id="text" placeholder="Type text...." ></textarea>
<button id="myButton" class="button">Count</button>
<textarea id="result" disabled></textarea>2 ответа
Я предполагаю, что Вы спрашиваете о дизайне по сравнению с шаблоном во время выполнения. Я общий я сказал бы "нет":
В то время как может быть возможно разделить Вашу базу данных в несколько контекстов данных, затем это было бы желательно, если и только если было нулевое перекрытие между этими двумя контекстами.
Перекрытие Плохо
например, у Вас есть a WebsiteContext и AdminContext. WebsiteContext для отображения Product и выполнение Orders.A WebsiteUser присоединен Order. AdminContext для Вашего Staff участники для обработки возмещений для отмененного Orders, который также ссылка WebsiteUser. AdminContext также потребности изменить пароли и обновить другие детали для WebsiteUser.
Вы думаете о выполнении этого, потому что Вы не хотите, чтобы веб-сайт обработал или даже знал о Returns
WebsiteContext
Product -- Order -- WebsiteUser
AdminContext
Staff -- Returns -- Order -- WebsiteUser
В вышеупомянутом мы видим, что копируем много объектов в различных Контекстах Данных. Это плохо пахнет, и это действительно указывает, что искусственно деление базы данных в различные контексты данных является неправильным решением. Вы имеете> 2 базы данных, в конце концов, или просто та? Дублирование нарушает принцип DRY (не Повторяйте Себя), потому что WebsiteContext. WebsiteUser не является тем же как AdminContext. WebsiteUser и по всей вероятности код будет грязным, когда что-то должно заботиться, на какой они ссылаются.
Контекст Данных Linq просто ИЛИ картопостроитель и должен рассматриваться как необычный черный квадрат, который делает запись части кода доступа к данным легче. Некоторые linq демонстрации делают, этому быть похожим на Вас больше не нужны другие слои, но программа любой сложности все еще извлекает выгоду из многоуровневой структуры.
Вы - вероятно, более обеспеченная обработка объектов Linq, так же просто возражает для того, чтобы легко передать данные, и создайте уровень Domain, который скрывает их как деталь реализации. Имейте чтение DDD - Доменный Управляемый Дизайн.
Самостоятельно, просто использование объектов Linq от UI больше всего напоминает Transaction Script шаблон. В таком случае Вы все еще извлекли бы выгоду из наличия логического слоя, который заботится о деталях.
В то время как Вы не можете хотеть обязанность контекста быть настолько широкими, контекст данных является просто представлением базы данных. Это не механизм защиты, и это не может препятствовать тому, чтобы Вы повредили данные.
От "угла" шаблона репозитория существует что-то, чтобы быть сказанным для того, чтобы иметь отдельные агрегаты и минимизировать свойства навигации между агрегатами. Я не на 100% уверен, что это что-то - то, хотя... в данный момент я рассматриваю использование умеренно измеренного dbml, с несколькими репозиториями с помощью него (UI не использует datacontexts непосредственно - только классы репозитория), со свойствами навигации, отмеченными внутренний, таким образом, DAL может использовать их... Возможно...