Используя Объект Платформа генерировала классы в Слое Бизнес-логики

Первое, что пришло на ум...

Функции

arguments.callee относится к функции, которая размещает переменную "аргументов", таким образом, это может использоваться для рекурсивного вызова анонимных функций:

var recurse = function() {
  if (condition) arguments.callee(); //calls recurse() again
}

Это полезно, если Вы хотите сделать что-то вроде этого:

//do something to all array items within an array recursively
myArray.forEach(function(item) {
  if (item instanceof Array) item.forEach(arguments.callee)
  else {/*...*/}
})

Объекты

интересная вещь об элементах объекта: у них может быть любая строка как их имена:

//these are normal object members
var obj = {
  a : function() {},
  b : function() {}
}
//but we can do this too
var rules = {
  ".layout .widget" : function(element) {},
  "a[href]" : function(element) {}
}
/* 
this snippet searches the page for elements that
match the CSS selectors and applies the respective function to them:
*/
for (var item in rules) {
  var elements = document.querySelectorAll(rules[item]);
  for (var e, i = 0; e = elements[i++];) rules[item](e);
}

Строки

String.split может взять регулярные выражения в качестве параметров:

"hello world   with  spaces".split(/\s+/g);
//returns an array: ["hello", "world", "with", "spaces"]

String.replace может взять регулярное выражение в качестве поискового параметра и функции как заменяющий параметр:

var i = 1;
"foo bar baz ".replace(/\s+/g, function() {return i++});
//returns "foo1bar2baz3"
6
задан skaffman 16 March 2012 в 09:39
поделиться

4 ответа

На мой взгляд, объекты EF будут сопоставлены с вашими. Это требует более высоких затрат на разработку, но дает дополнительное преимущество в виде игнорирования настойчивости и разделения. Такое разделение может привести к значительной гибкости и реальной экономии в долгосрочной перспективе, если бизнесу потребуется переключиться на другое решение для обеспечения устойчивости. Без разделения объекты EF могут быть глубоко встроены в уровни BLL и даже представления, что потребует огромного рефакторинга. В таком случае бизнес может даже не рассматривать вопрос о переходе на постоянные решения, что может привести к снижению конкурентоспособности бизнеса.

Решение получить эту выгоду при более высоких затратах на разработку зависит от степени риска, на который готов пойти бизнес. взять.

5
ответ дан 16 December 2019 в 21:41
поделиться

Использование сгенерированных классов в качестве бизнес-объектов должно быть разумным. Сгенерированные классы являются частичными, поэтому вы можете легко расширять их по своему усмотрению. Однако иногда мне кажется более удачным вариантом использовать интерфейсы.

2
ответ дан 16 December 2019 в 21:41
поделиться

Я только что начал работать с EF 2.0 (в .Net 4.0 beta 2), и в нем есть возможность использовать классы POCO в качестве объектов EF. т.е. теперь в EF 2 можно использовать классы, игнорирующие персистентность.
Я думаю, что это еще не полностью готово, так как я не мог следить за презентацией PDC 2009 при работе в Visual Studio 2010 beta 2, но следите за этим в блоге команды ADO.Net .

]
1
ответ дан 16 December 2019 в 21:41
поделиться

Вы можете посмотреть адаптер Persistence Ignorance (POCO) для Entity Framework . Это проект с открытым исходным кодом от члена команды EF, который обеспечивает поддержку POCO для EF 1.0. EF 4.0 будет иметь поддержку POCO "из коробки", но этот проект служит временной мерой до тех пор, пока .NET 4.0 не упадет в 2010 году.

0
ответ дан 16 December 2019 в 21:41
поделиться
Другие вопросы по тегам:

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