Pull to refresh
12
0
Send message
То-то для некоторых задач используют уравнения Максвелла, для некоторых квантовую теорию, а для некоторых закон Кулона. Причем во всех трех случаях задачи по электрическому взаимодействию. Какой из трех подходов назначим общественно значимым?
С точки зрения эволюции гораздо эффективнее один раз вложиться государству или мировому сообществу (вспомним, например, Большой адронный коллайдер)

Большой адронный коллайдер — это конечно круто, Но в него вкладывалось не мировое сообщество целиком, а конкретные научные организации (да, их было много). И у этого коллайдера есть десяток конкурентов поменьше.
Ну вообще издатели — это такие инвесторы. Приходит автор, говорит я хочу написать и издать книгу, для этого мне нужно столько то денег. Дальше издательство вносит свою долю деньгами (а так же работами по продвижению и изданию написанной книги), автор — написанием текста книги. Дальше после издания книги они оба получают прибыль окупая затраты (да, там есть ньюансы с тем когда автор начинает получать эту прибыль (роялти), но это зависит от конкретного договора). Если автора схема не устраивает — он может пойти взять кредит в банке под залог, например, квартиры и издаваться сам. Вся прибыль будет его (за исключением процентов банка), однако если не окупится — отвечать по кредиту тоже будет только он.
Но самое главное, что по факту, если не использовать нормальные исключения (т.е., использовать FaultException), то выясняется, что в WCF паттерн, описанный в статье, прекрасно реализуется без какого-либо велосипеда.

Вот да. Проще всего собрать все валидационные сообщения, положить их в коллекцию и только после этого бросить FaultException типизованный этой коллекцией. А на клиенте спокойно разобрать эту коллекцию валидационных сообщений как нужно.
В wcf нужно кидать FaultException (потому что он преобразуется в описанный стандартом SoapFault).
То есть не для пруф оф концепт вы не будете использовать быструю сортировку (типичный случайный(вероятностный) алгоритм)?
Простите, но на опечатку это не похоже. Больше похоже на то, что статью писал человек не разбирающийся.
Процедуры хранения в бд — это что за зверь такой?
То что lair описал — это не наследование, а декоратор:

     public class BaseClass
     {
           public void DoSmthng(obj param)
           {
                 .....
           }
     }

     public class Wrapper
     {
           private BaseClass _innerObj = new BaseClass();           

           public void DoSmthng(obj param)
           {
                 ...
                 _innerObj.DoSmthng(param);
           }
     }     
Я в таких случаях в ответ спрашиваю правда ли такой код встречается в репозитории. И если да, то для меня это сигнал не идти сюда.
Слушай, ну я знаю про Ctrl-F5, но спрашивали же зачем ридлайн. Я объяснил зачем он по моему мнению.
Чтобы консоль не закрывалась и можно было посмотреть результат.
Угу. поэтому, видимо, вынесение решарпера в отдельный процесс решит проблему с кончающейся памятью? Я, если что, тоже работаю с решарпером на большом проекте (около 100 проектов в солюшне). И основная проблема там в недостатке памяти.
Вы бы почитали что авторы пишут. Отдельный процесс решарпера там потому что IDE на Java. Они не захотели портировать решарпер на Java. Поэтому отдельный процесс и обмен с помощью бинарного протокола.
Так вот, то что вы сделаете с высшим образованием, приведет к тому, что выпускники вузов тоже не будут обладать квалификацией. И да, чтобы вы знали, специальность «Программист» — это специальность среднего специального заведения (ПТУ и иже с ним).
Слушайте, ну не нужны вам сотрудники с высшим образованием, а ПТУ-щники, ну и набирайте их. В чем проблема-то? Там уже выполняется все что вы хотите:
1. вступительные экзамены? чистая формальность.
2. выпускные экзамены — тоже самое.
3. Независимые сертификации — да полно их. А если не устраивают — сделайте свою.

Зачем вы хотите сломать текущее высшее образование мне не понятно.
А зачем мне ваша обертка над коннекшн пулом?
Не должен. По определению паттерна Dependency Injection классу-клиенту безразличны любые аспекты реализации зависимости. Значение имеет только контракт (интерфейс).

Ну так либо интерфейс зависимости является IDisposable и тогда клиент знает что любая пришедшая сюда зависимость Disposable (и это не деталь реализации а контракт), либо не нужно ее диспозить.

Предположим, у вас есть такой ресурс, как соединение (IConnection)
Его контракт не допускает параллельное использование в нескольких разных задачах.
Поддержка соединения в рабочем состоянии кое-чего стоит, но создание нового.гораздо дороже.
Вы хотите полностью развязать себе руки в части выбора способа управления соединениями, при этом сохранив все возможности достичь максимальной эффективности.
Нет никакого смысла позволять клиентам делать вызов Dispose для соединения, так как вам вовсе не нужно закрывать его каждый раз.
Но нельзя давать соединение новому клиенту, если его еще использует старый.


Про коннекшн пул не слышали? Типовой паттерн.
Так вот вопрос, зачем вы называете свой интерфейс так же как уже существующий, с устоявшейся семантикой? Чтобы было проще?

Information

Rating
Does not participate
Registered
Activity