Типичное легко-расширяемое веб приложение(интернет магазин/форум/блог/каталог/веб сервис по обработке какихх-то данных):
Приложение разделено на две части:
1.FE html+js+css
2.BE asp.net webservices
Хоститься на одном вебсайте-ip адресе, но вебсервисы — под-приложение. FE показывает html страничку и по необходимости дергает методы вебсервисов .
FE — может писаться на ангуляре/кастомного js/__подставить свое.
BE.
Базовый контроллер, содержит информацию о сессии, о пользователе и информацию которая нужна в почти во всех запросах на сервер. От базового контрллера будут унаследованы практически все контроллеры.
Аттрибут `exception` — это "фильтр", который перехватывает все exceptions, логирует и если нужно возвращает клиенту сеарилизованную ошибку в json или HTTP CODE.
[exception]
public class baseController : ApiController
{
public session session { get; internal set; }
public domain.servicemodels.user.user user{ get; internal set; }
}
Пример типичного контроллера.
"фильтр" `auth` говорит, что только аутентифицированные пользователи могут вызывать данный контроллер.
"фильтр" `authorz` — говорит какие роли должны быть у этого пользователя, что бы он мог вызвать контроллер.
аттрибут service — говорит что только HTTP POST запрос может быть выполнен к этому методу; т.к. PUT,DELETE -это недоработки/костыли HTTP протокола, в реальной жизни они ненужны, все запросы к сервисам будут идти только через POST, буд-то мы создаем еще один уровень в сетевой моделе OSI. HTTP GET нужен только для браузеров для скачивания html или js, тоже недостаток HTTP протокола, можно было бы спокойно жить с одним POST, отсылая еще как параметр время жизни данных, которые отдал сервер.
В теле контроллера, идет базовая обработка кода, по необходимости, достаются нужные конфиги, конвертируются входящие параметры в нужные объекты.
[auth]
public class carController : baseController
{
[authorz(roles.user,roles.admin)]
[service]
public rr delete(car car)
{
var s = new carservice();
return s.delete(car, this.user);
}
}
Каждый метод контроллера, будет возращать код ошибки/кастомной ошибки с описанием.
public enum responce_codes
{
// Action was handled well, without errors
success = 0,
// HTTP parameters(from body|url) not valid
bad_request = 400,
unauthorized = 401,
forbidden=403,
internal_server_error = 500,
...
}
public class error {
public string name { get; set; }
public string message { get; set; }
}
public class rr : error
{
public responce_codes code { get; set; }
public IEnumerable<error> errors { get; set; }
}
Типичный сервис с бизнес логикой.
В метод `delete` передаются данные, которые будут проверены: базовая валидация, потом запросы к бд, какая-то логика, конвертация прокси/адаптером классом в объект — Responce для клиента, в котором не будет содержаться лишних данных.
В блоке `using (var context = new xcontext())` -создает соединение с бд, достаются необходимые данные, обрабатываются и закрывается соединение.
`invalid_data_exception` — кастомное исключение, которое будет обрабатываться в `exception` фильтре
public class carservice
{
public rr delete(servicemodels.car.car car, servicemodels.user.user user)
{
var date = DateTime.UtcNow;
if (user.shop == null || car == null)
{
throw new invalid_data_exception();
}
using (var context = new xcontext())
{
var carsmanager = new carsmanager(context);
var usersmanager = new usersmanager(context);
var carproxy = new carproxy();
var update_car = carsmanager
.list_by_shop_not_deleted(user.shop.id)
.FirstOrDefault(x=>x.id==car.id);
if (update_car==null)
{
throw new invalid_data_exception();
}
...
update_car.deletedate = date;
carsmanager.update(update_car);
context.SaveChanges();
return new rr();
}
}
}
Все никакого лишнего кода, все красиво, все работает,
мы всегда знаем что в каждый метод сервиса будут переданы только те данные/конфиги, которые ему нужны для выполнения логики, потом будет проверка входящих данных, а после, если нам надо, а не при каждом request|responce, будет создано соединени с бд/диском, а ты только клепай контроллеры да методы.
Где можно применить Dependency Injection что бы упростить себе жизнь?
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, IQuerist, Вы писали:
J>>А как можно интегрировать какой-то IoC напр. Autofac(или любой другой) , что бы он работал как DI, а не как SL?
IQ>см. http://rsdn.org/forum/design/6512200.1
Можно сказать что DI — это самый типичный способ рефакторинга кода, вынесения общих частей — логики по обработке данных в отдельные модули.
Сначала у нас есть длинная функция, в которой инициализируются какие-то данные, потом вызывает еще ряд функций, которые внутри инициализируют дополнительные данные.
1. --
void func(){
var controller=new controller();
int z=controller.calc(5,10);
int w=controller.edit(z);
}
class controller{
int calc(int x,int y){
int s=x>0?1:2;
return x+y+s;
}
int edit(int z){
int s=z>0?3:4;
return z+s;
}
}
Подрефакторим, вынесем код переиспользуемый код в класс `super`.
2. --
void func(){
var controller=new controller();
int z=m.calc(5,10);
int w=m.edit(z);
}
class super{
int check1(int s){
return s>0?1:2;
}
int check2(int s){
return s>0?3:4;
}
}
class controller{
int calc(int x,int y){
var super=new super();
int s=super.check1(x);
return x+y+s;
}
int edit(int z){
var super=new super();
int s=super.check2(z);
return z+s;
}
}
Видим, что класс `super` используется в нескольких местах, вынесем его инициализвацию в конструктор. (что бы можно было сделать см. шаг 4.)
3. --
void func(){
var super=new super();
var controller=new controller(super);
int z=controller.calc(5,10);
int w=controller.edit(z);
}
class super{
int check1(int s){
return s>0?1:2;
}
int check2(int s){
return s>0?3:4;
}
}
class controller{
super super;
controller(super super){
this.super=super;
}
int calc(int x,int y){
int s=super.check1(x);
return x+y+s;
}
int edit(int z){
int s=super.check2(z);
return z+s;
}
}
и вдруг у нас может добавится еще один какой-то пользовательский параметр настроек в класс `super` или наоборот надо какие-то параметры `h,g,w,u` иницилизировать где-то повыше в коде(напр. что бы еще где-то переиспользовать или что бы пользователь мог их сам задавать и т.д.), добавим класс `config`
4. --
void func(){
var config=new config{h=1,g=2,w=3,u=4};
var super=new super(config);
var controller=new controller(super);
int z=controller.calc(5,10);
int w=controller.edit(z);
}
class config{
int h;
int g;
int w;
int u;
}
class super{
config config;
super(config config){
this.config=config;
}
int check1(int s){
return s>0?config.h:config.g;
}
int check2(int s){
return s>0?config.w:config.u;
}
}
class controller{
super super;
controller(super super){
this.super=super;
}
int calc(int x,int y){
int s=super.check1(x);
return x+y+s;
}
int edit(int z){
int s=super.check2(z);
return z+s;
}
}
В некоторых случаях достаточно первого варианта, в некоторых надо сразу делать как в 4м примере.
--
Представим что класс `controller` — это самый обычный контроллер из asp.net web api.
Но, у нас нет возможности самим создавать контроллеры (можем, но в самом простом случае за нас это сделает asp.net web api фремверк)
void func(){
//.. это за нас делает фремверк .. где-то там далеко внутри своего кода
// var controller=new controller(super);
// int z=controller.calc(5,10);
// int w=controller.edit(z);
}
class configs{
super get_default_super(){
var config=new config{h=1,g=2,w=3,u=4};
return new super(config);
}
}
class controller{
super super;
controller(){
this.super=configs.get_default_super();
}
int calc(int x,int y){
int s=super.check1(x);
return x+y+s;
}
int edit(int z){
int s=super.check2(z);
return z+s;
}
}
И у нас появляется выбор.
1. Вызывать в каждом контроллере — его конструкторе/в мтеоде инициализацию нужных конфигов.
2. Воспользоваться AutofacX-ом: в Global.asax прописать, для таких-то контроллеров, при вызове его конструктора, инициализировать объект `super` такими-то данными
void func(){
// эта функция определена в Global.asax и вызывается при первом запуске приложения.var super=configs.get_default_super();
AutofacX.Register(typeof(controller),typeof(service),super);
}
class configs{
super get_default_super(){
var config=new config{h=1,g=2,w=3,u=4};
return new super(config);
}
}
class controller{
super super;
controller(super){
this.super=configs.get_default_super();
}
int calc(int x,int y){
int s=super.check1(x);
return x+y+s;
}
int edit(int z){
int s=super.check2(z);
return z+s;
}
}
Второй вариант лучше, т.к. он сокращает количество мест инициализации этих самых базовых данных.
!--
Можно сделать вывод:
DI контейнер надо использовать, когда у нас какие-то объекты создаются рефлексией и у нас нет явного доступа к коду их создания, что бы передать в конструктор нужные нам данные (как в примере с контроллерами).
Но если приложение не сильно большое, на базовых этапах его развития, вполне сгодиться код без DI контейнеров -иссользования Синглтонов, напр. для логгирования, напр. пусть мы используем Nlog либу(мы можем названия логгеров протянуть в разные аттрибуты/контроллеры с помощью DI containera) т.к. логгеров у нас не много, мы просто создаем статический класс/функцию которая нам возвращает список имен логгеров, используем стандартную функцию Nlog, которая по названию функции возращает нам логгер и мы его используем. В будущем если будет время и не лень, такой код не сложно будет подрефакторить и переписать с помощью DI контейнера.
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, #John, Вы писали:
J>Можно сделать вывод: J>DI контейнер надо использовать, когда у нас какие-то объекты создаются рефлексией и у нас нет явного доступа к коду их создания, что бы передать в конструктор нужные нам данные (как в примере с контроллерами).
Какие данные вам нужно передавать в контроллер? Контроллер это не универсальный процессор бизнес логики это всего лишь прослойка между web инфраструктурой и вашим приложением. Все что вам доступно в контроллере это данные web (http запрос, cookies, переменные окружения сервера) все что контроллер должен сделать — замапить web данные на entity классы бизнес логики и вызвать соотв. обработчик бизнес логики. Имхо маппинг должен быть явным, т.к. иначе эта логика мапинга начнет размазываться по бизнес логике и внезапно бизнес транзакции начнут например напрямую зависеть от деталей формата данных клиентских форм которые собираются на клиенте через javascript.
Re[6]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, IQuerist, Вы писали:
IQ>Здравствуйте, #John, Вы писали:
IQ>Какие данные вам нужно передавать в контроллер?
При первом запуске приложения, в Global.asax, считываются разные конфиги, напр. из Web.config список путей к разным утилитам на диске c:\bin, к данным(картикам, докам), виртуальные пути, email адреса, ftp_creds. Записываются в сервис/модельку(напр. которая умеет работать с вирт путями).
class Global.asax{
public func();
var configs=configs.get_configs_from_web_config_that_work_with_path();
// сервис который умеет генерить pdf-ыvar pdfservice=new pdfservice(configs);
AutofacX.Register("*Controller",typeof(pdfservice),pdfservice);
}
}
class carController{
public pdfservice;
public carController(pdfservice pdfservice){
this.pdfservice=pdfservice;
}
public rr pdfgenerate(pdfmodel pdfmodel){
return this.pfdservice.generate(pdfmodel);
}
}
Вот и получается, что таким образом, мы протаскиваем в контроллер разные конфиги.
>>Все что вам доступно в контроллере это данные web (http запрос, cookies, переменные окружения сервера) все что контроллер должен сделать — замапить web данные на entity классы бизнес логики и вызвать соотв. обработчик бизнес логики.
Да, именно так. >>транзакции начнут например напрямую зависеть от деталей формата данных клиентских форм которые собираются на клиенте через javascript.
Было пару раз такое, что отдельно был написан клиент(3й стороной), и отдельно сервисы — добавил еще один слой с прокси классами, который конвертил входящие параметры и ответ сервисов, в модели, которые ожидал клиент. Но, дополнительный слой внес небольшие сложности, когда менялась бизнес логика(сервисов и клиента), когда добавлялись новые поля в моделях.
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, #John, Вы писали:
J>Здравствуйте, IQuerist, Вы писали:
IQ>>Здравствуйте, #John, Вы писали:
IQ>>Какие данные вам нужно передавать в контроллер? J>При первом запуске приложения, в Global.asax, считываются разные конфиги, напр. из Web.config список путей к разным утилитам на диске c:\bin, к данным(картикам, докам), виртуальные пути, email адреса, ftp_creds. Записываются в сервис/модельку(напр. которая умеет работать с вирт путями).
J>
J>class Global.asax{
J>public func();
J> var configs=configs.get_configs_from_web_config_that_work_with_path();
J> // сервис который умеет генерить pdf-ы
J> var pdfservice=new pdfservice(configs);
J> AutofacX.Register("*Controller",typeof(pdfservice),pdfservice);
J>}
J>}
J>class carController{
J> public pdfservice;
J> public carController(pdfservice pdfservice){
J> this.pdfservice=pdfservice;
J> }
J> public rr pdfgenerate(pdfmodel pdfmodel){
J> return this.pfdservice.generate(pdfmodel);
J> }
J>}
J>
J>Вот и получается, что таким образом, мы протаскиваем в контроллер разные конфиги.
Абажаю такие решения! Код просто кричит — да гори этот ваш бекэнд код изгаженный DI container синим пламенем, мы лучше сделаем всю нужную бизнес логику на клиенте, на javascript хорошо что вы туда не суетесь )))
>>>транзакции начнут например напрямую зависеть от деталей формата данных клиентских форм которые собираются на клиенте через javascript. J>Было пару раз такое, что отдельно был написан клиент(3й стороной), и отдельно сервисы — добавил еще один слой с прокси классами, который конвертил входящие параметры и ответ сервисов, в модели, которые ожидал клиент. Но, дополнительный слой внес небольшие сложности, когда менялась бизнес логика(сервисов и клиента), когда добавлялись новые поля в моделях.
Небольшие сложности? Вам не пришлось отлавливать ошибки связанные с изменениями в рантайме.
Здравствуйте, #John, Вы писали:
J>Вот и получается, что таким образом, мы протаскиваем в контроллер разные конфиги.
А нельзя просто куда-нибудь подсунуть свою фабрику контроллеров, чтобы избежать эту рефлективную бяку?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, #John, Вы писали:
J>>Вот и получается, что таким образом, мы протаскиваем в контроллер разные конфиги. ·>А нельзя просто куда-нибудь подсунуть свою фабрику контроллеров, чтобы избежать эту рефлективную бяку?
меня сильно огорчила картинка — там где по смыслу при TDD получается красивая схема с единым API в центре... Я так понимаю дядя боб совсем сдал, т.к. в реальности, разных API там будет целая куча с кучей связей между ними. Т.е. в целом, правая схема ничем не будет отличаться от левой схемы.
Здравствуйте, IQuerist, Вы писали:
IQ>·>А нельзя просто куда-нибудь подсунуть свою фабрику контроллеров, чтобы избежать эту рефлективную бяку? IQ>Мартин кстати недавно разразился статьей IQ>TDD Harms Architecture IQ>http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html
Тут заголовок не соответствует содержанию, в выводе написано: TDD is a professional discipline that all programmers should learn and practice. ... Is is only programmers, not TDD, that can do harm to designs and architectures.
IQ>на деле — DI frameworks Harms Architecture
на деле — бездумное использование {X} Harms Architecture.
IQ>меня сильно огорчила картинка — там где по смыслу при TDD получается красивая схема с единым API в центре... Я так понимаю дядя боб совсем сдал, т.к. в реальности, разных API там будет целая куча с кучей связей между ними. Т.е. в целом, правая схема ничем не будет отличаться от левой схемы.
Ага. Либо я что-то не понял что он хотел этой схемой показать, либо просто лажа.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, #John, Вы писали:
J>>Вот и получается, что таким образом, мы протаскиваем в контроллер разные конфиги. ·>А нельзя просто куда-нибудь подсунуть свою фабрику контроллеров, чтобы избежать эту рефлективную бяку?
Можно, но придется написать пару доп. классов для создания контроллеров. Конечно по правильному надо было бы так сделать и сервисы производительней бы стали работать. Но, пока нет проблем с производительностью и контроллеры вызываются только из одного места(рефлексией в asp.net web api фремверке), реализовывать свою фабрику контроллеров не вижу смысла — т.к. сейчас очевидно какой объект с данными попадет в конструктор контроллера.
Еще можно добавить, что если нам приходится реализовывать свою фабрику контроллеров — это недостаток asp.net web api фремверка, т.к. решение из коробки вообще никуда не годится.
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>·>А нельзя просто куда-нибудь подсунуть свою фабрику контроллеров, чтобы избежать эту рефлективную бяку? IQ>>Мартин кстати недавно разразился статьей IQ>>TDD Harms Architecture IQ>>http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html ·>Тут заголовок не соответствует содержанию, в выводе написано: TDD is a professional discipline that all programmers should learn and practice. ... Is is only programmers, not TDD, that can do harm to designs and architectures.
А вовсе не "когда в руках молоток, все вокруг выглядит как гвозди" )))
IQ>>на деле — DI frameworks Harms Architecture ·>на деле — бездумное использование {X} Harms Architecture.
Это да, но в статье боба ссылка на видео Jim Weirich on Decoupling from Rails где он как раз говорит о DI frameworks.
IQ>>меня сильно огорчила картинка — там где по смыслу при TDD получается красивая схема с единым API в центре... Я так понимаю дядя боб совсем сдал, т.к. в реальности, разных API там будет целая куча с кучей связей между ними. Т.е. в целом, правая схема ничем не будет отличаться от левой схемы. ·>Ага. Либо я что-то не понял что он хотел этой схемой показать, либо просто лажа.
Имхо отрасль в идейном тупике, а в TDD вложили слишком много пеара, чтобы теперь признать, что никаких принципиальных проблем эти практики не решают.
Re[9]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, #John, Вы писали:
J>>>Вот и получается, что таким образом, мы протаскиваем в контроллер разные конфиги. J>·>А нельзя просто куда-нибудь подсунуть свою фабрику контроллеров, чтобы избежать эту рефлективную бяку? J>Можно, но придется написать пару доп. классов для создания контроллеров.
Так это даже звучит проще, чем тащить ещё целый фреймворк типа autofac.
J>Конечно по правильному надо было бы так сделать и сервисы производительней бы стали работать. Но, пока нет проблем с производительностью и контроллеры вызываются только из одного места(рефлексией в asp.net web api фремверке), реализовывать свою фабрику контроллеров не вижу смысла — т.к. сейчас очевидно какой объект с данными попадет в конструктор контроллера.
Тесты заодно упростятся.
J>Еще можно добавить, что если нам приходится реализовывать свою фабрику контроллеров — это недостаток asp.net web api фремверка, т.к. решение из коробки вообще никуда не годится.
Гы-гы. Удивил.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, IQuerist, Вы писали:
IQ>>>на деле — DI frameworks Harms Architecture IQ>·>на деле — бездумное использование {X} Harms Architecture. IQ>Это да, но в статье боба ссылка на видео Jim Weirich on Decoupling from Rails где он как раз говорит о DI frameworks.
Не удивительно. Это всё aftershock после засилия UML и прочего enterprise.
IQ>>>меня сильно огорчила картинка — там где по смыслу при TDD получается красивая схема с единым API в центре... Я так понимаю дядя боб совсем сдал, т.к. в реальности, разных API там будет целая куча с кучей связей между ними. Т.е. в целом, правая схема ничем не будет отличаться от левой схемы. IQ>·>Ага. Либо я что-то не понял что он хотел этой схемой показать, либо просто лажа. IQ>Имхо отрасль в идейном тупике, а в TDD вложили слишком много пеара, чтобы теперь признать, что никаких принципиальных проблем эти практики не решают.
Именно как "дисциплина" — это правильно. Ведь такие вещи как version control system или issue tracker тоже никаких принципиальных проблем не решают, но без них средняя температура по больнице будет ниже.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>>>на деле — DI frameworks Harms Architecture IQ>>·>на деле — бездумное использование {X} Harms Architecture. IQ>>Это да, но в статье боба ссылка на видео Jim Weirich on Decoupling from Rails где он как раз говорит о DI frameworks. ·>Не удивительно. Это всё aftershock после засилия UML и прочего enterprise.
Чем вам помешал безобидный и бессмысленный UML? )))
IQ>>>>меня сильно огорчила картинка — там где по смыслу при TDD получается красивая схема с единым API в центре... Я так понимаю дядя боб совсем сдал, т.к. в реальности, разных API там будет целая куча с кучей связей между ними. Т.е. в целом, правая схема ничем не будет отличаться от левой схемы. IQ>>·>Ага. Либо я что-то не понял что он хотел этой схемой показать, либо просто лажа. IQ>>Имхо отрасль в идейном тупике, а в TDD вложили слишком много пеара, чтобы теперь признать, что никаких принципиальных проблем эти практики не решают. ·>Именно как "дисциплина" — это правильно. Ведь такие вещи как version control system или issue tracker тоже никаких принципиальных проблем не решают, но без них средняя температура по больнице будет ниже.
Не согласен, именно version control system и issue tracker решают принципиальные проблемы работы в команде связанные с коммуникативными транзакциями как с другими разработчиками так и с аналитиком. И собственно тут критерии простые — возможность мержить конфликтный код и возможность хранить обсуждение артефактов разработки (issue tracker)
TDD имхо не имеет вообще никаких критериев и имхо никак не может быть оценен.
Re[10]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, #John, Вы писали:
J>>>>Вот и получается, что таким образом, мы протаскиваем в контроллер разные конфиги. J>>·>А нельзя просто куда-нибудь подсунуть свою фабрику контроллеров, чтобы избежать эту рефлективную бяку? J>>Можно, но придется написать пару доп. классов для создания контроллеров. ·>Так это даже звучит проще, чем тащить ещё целый фреймворк типа autofac.
А главное это будет абсолютно прозрачно и очевидно. Плюс скорее всего добавиться семантика при именовании.
Re[13]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, IQuerist, Вы писали:
IQ>>>Это да, но в статье боба ссылка на видео Jim Weirich on Decoupling from Rails где он как раз говорит о DI frameworks. IQ>·>Не удивительно. Это всё aftershock после засилия UML и прочего enterprise. IQ>Чем вам помешал безобидный и бессмысленный UML? )))
Чем-чем... Безобидностью и бессмысленностью
IQ>>>Имхо отрасль в идейном тупике, а в TDD вложили слишком много пеара, чтобы теперь признать, что никаких принципиальных проблем эти практики не решают. IQ>·>Именно как "дисциплина" — это правильно. Ведь такие вещи как version control system или issue tracker тоже никаких принципиальных проблем не решают, но без них средняя температура по больнице будет ниже. IQ>Не согласен, именно version control system и issue tracker решают принципиальные проблемы работы в команде связанные с коммуникативными транзакциями как с другими разработчиками так и с аналитиком. И собственно тут критерии простые — возможность мержить конфликтный код и возможность хранить обсуждение артефактов разработки (issue tracker)
Если уж подходить предвзято — это не критерии. Да и вообще, мерж конфликтов сам по себе — сигнал плохо поставленного процесса разработки. А обсуждать артефакты можно по емейлу. Создал пару excel spreadsheets и что ещё для счастья надо?!
IQ>TDD имхо не имеет вообще никаких критериев и имхо никак не может быть оценен.
Он позволяет значительно сократить время от написания кода до его исполнения. А так же предоставляет формальный способ коммуникации — код тестов это по сути исполняемая документация.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>>>Это да, но в статье боба ссылка на видео Jim Weirich on Decoupling from Rails где он как раз говорит о DI frameworks. IQ>>·>Не удивительно. Это всё aftershock после засилия UML и прочего enterprise. IQ>>Чем вам помешал безобидный и бессмысленный UML? ))) ·>Чем-чем... Безобидностью и бессмысленностью
IQ>>Не согласен, именно version control system и issue tracker решают принципиальные проблемы работы в команде связанные с коммуникативными транзакциями как с другими разработчиками так и с аналитиком. И собственно тут критерии простые — возможность мержить конфликтный код и возможность хранить обсуждение артефактов разработки (issue tracker) ·>Если уж подходить предвзято — это не критерии. Да и вообще, мерж конфликтов сам по себе — сигнал плохо поставленного процесса разработки.
))) Не ясно как можно избежать мерджа если хотя бы два программера пилят один и тот же проект.
IQ>>А обсуждать артефакты можно по емейлу. Создал пару excel spreadsheets и что ещё для счастья надо?!
Можно, но тогда потеряется история. Да и искать артефакты в тоннах прочего коммуникационного хлама, у меня например плохо получается.
IQ>>TDD имхо не имеет вообще никаких критериев и имхо никак не может быть оценен. ·>Он позволяет значительно сократить время от написания кода до его исполнения.
)))Поправочка он может сократить, а может и не сократить ))) и вы никогда не обьясните как добиться первого и избежать второго.
>>>А так же предоставляет формальный способ коммуникации — код тестов это по сути исполняемая документация.
Осталось определиться с критериями полноты и актуальности )))
Re[15]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, IQuerist, Вы писали:
IQ>>>Не согласен, именно version control system и issue tracker решают принципиальные проблемы работы в команде связанные с коммуникативными транзакциями как с другими разработчиками так и с аналитиком. И собственно тут критерии простые — возможность мержить конфликтный код и возможность хранить обсуждение артефактов разработки (issue tracker) IQ>·>Если уж подходить предвзято — это не критерии. Да и вообще, мерж конфликтов сам по себе — сигнал плохо поставленного процесса разработки. IQ>))) Не ясно как можно избежать мерджа если хотя бы два программера пилят один и тот же проект.
Ну как-как... Как люди писали софт лет 20 назад? Только Вася может трогать DAO-классы. А ты, Петя, можешь трогать только Controller-классы, и не смей больше трогать DAO — опять всё поломаешь, если надо — обращайся к Васе, он всего через 3 недели из отпуска вернётся, у него найдётся время, наверное.
IQ>>>А обсуждать артефакты можно по емейлу. Создал пару excel spreadsheets и что ещё для счастья надо?! IQ>Можно, но тогда потеряется история. Да и искать артефакты в тоннах прочего коммуникационного хлама, у меня например плохо получается.
Зачем тебе история? Сиди пиши код.
IQ>>>TDD имхо не имеет вообще никаких критериев и имхо никак не может быть оценен. IQ>·>Он позволяет значительно сократить время от написания кода до его исполнения. IQ>)))Поправочка он может сократить, а может и не сократить ))) и вы никогда не обьясните как добиться первого и избежать второго.
Угу. И использование системы контроля версий может дать возможность мержить, а может и не дать. Попробуй помержь какие-нибудь файлы проектов или .rc в вижуал-студиях каких-нибудь...
>>>>А так же предоставляет формальный способ коммуникации — код тестов это по сути исполняемая документация. IQ>Осталось определиться с критериями полноты и актуальности )))
Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[16]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, ·, Вы писали:
IQ>>·>Если уж подходить предвзято — это не критерии. Да и вообще, мерж конфликтов сам по себе — сигнал плохо поставленного процесса разработки. IQ>>))) Не ясно как можно избежать мерджа если хотя бы два программера пилят один и тот же проект. ·>Ну как-как... Как люди писали софт лет 20 назад? Только Вася может трогать DAO-классы. А ты, Петя, можешь трогать только Controller-классы, и не смей больше трогать DAO — опять всё поломаешь, если надо — обращайся к Васе, он всего через 3 недели из отпуска вернётся, у него найдётся время, наверное.
Вспоминаю детство увы такой подход несерьезный )))
IQ>>>>А обсуждать артефакты можно по емейлу. Создал пару excel spreadsheets и что ещё для счастья надо?! IQ>>Можно, но тогда потеряется история. Да и искать артефакты в тоннах прочего коммуникационного хлама, у меня например плохо получается. ·>Зачем тебе история? Сиди пиши код.
Я в недоумении ))) я конечно не работаю на "больших проектах", но даже у меня на четверти change request аналитики делают более 5 изменений.
IQ>>>>TDD имхо не имеет вообще никаких критериев и имхо никак не может быть оценен. IQ>>·>Он позволяет значительно сократить время от написания кода до его исполнения. IQ>>)))Поправочка он может сократить, а может и не сократить ))) и вы никогда не обьясните как добиться первого и избежать второго. ·>Угу. И использование системы контроля версий может дать возможность мержить, а может и не дать. Попробуй помержь какие-нибудь файлы проектов или .rc в вижуал-студиях каких-нибудь...
))) я мержил все ))) ни один текстовый мерж не имеет ни шанса )))
>>>>>А так же предоставляет формальный способ коммуникации — код тестов это по сути исполняемая документация. IQ>>Осталось определиться с критериями полноты и актуальности ))) ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе?
))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота.
Как измерить полноту? Хороший вопрос, вероятно по количеству обращений за пояснениями к заказчику... в случае если проект будет принят. Если он не принят значит обращений было не достаточно )))
Re[17]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, IQuerist, Вы писали:
IQ> ·>Ну как-как... Как люди писали софт лет 20 назад? Только Вася может трогать DAO-классы. А ты, Петя, можешь трогать только Controller-классы, и не смей больше трогать DAO — опять всё поломаешь, если надо — обращайся к Васе, он всего через 3 недели из отпуска вернётся, у него найдётся время, наверное. IQ> Вспоминаю детство увы такой подход несерьезный )))
Работает же!
IQ> ·>Угу. И использование системы контроля версий может дать возможность мержить, а может и не дать. Попробуй помержь какие-нибудь файлы проектов или .rc в вижуал-студиях каких-нибудь... IQ> ))) я мержил все ))) ни один текстовый мерж не имеет ни шанса )))
Для этого СКВ не обязательна!
IQ> IQ>>Осталось определиться с критериями полноты и актуальности ))) IQ> ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе? IQ> ))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота.
Код должен обеспечивать бизнес-функционал. Тесты должны тестировать код. Значит тесты тестируют бизнес-функционал.
В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.
IQ> Как измерить полноту? Хороший вопрос, вероятно по количеству обращений за пояснениями к заказчику... в случае если проект будет принят. Если он не принят значит обращений было не достаточно )))
IQ>> IQ>>Осталось определиться с критериями полноты и актуальности ))) IQ>> ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе? IQ>> ))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота. ·>Код должен обеспечивать бизнес-функционал. Тесты должны тестировать код. Значит тесты тестируют бизнес-функционал.
Увы, бизнес функционал может быть вообще не связан с написанным кодом, например если аналитики "сработали плохо". Бизнес функционала вообще (части бизнес функционала) может вообще не быть ))) т.к. ее планирую стартовать после релиза проекта. Ну и что хуже всего бизнес функционал скорее всего измениться в процессе эксплуатации проекта, этого не будет в коде соотв. этого не будет в тестах.
Имхо бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и конечно же за пределами кода. Что уж тут говорить по поводу тестов.
И это я еще не беру в рассчет ошибки программера.
·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.
В вашей фразе кстати бездна философского смысла! (без сарказма) Но в этой реальности бизнес не знает о юнит тестах)))
Здравствуйте, IQuerist, Вы писали:
IQ>>> ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе? IQ>>> ))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота. IQ>·>Код должен обеспечивать бизнес-функционал. Тесты должны тестировать код. Значит тесты тестируют бизнес-функционал. IQ>Увы, бизнес функционал может быть вообще не связан с написанным кодом, например если аналитики "сработали плохо". Бизнес функционала вообще (части бизнес функционала) может вообще не быть ))) т.к. ее планирую стартовать после релиза проекта. Ну и что хуже всего бизнес функционал скорее всего измениться в процессе эксплуатации проекта, этого не будет в коде соотв. этого не будет в тестах.
Непонятно. В этом случае пользователи будут ворчать, что программа делает не то, что надо. Конечно, тесты не могут гарантировать, что реализованный функционал работает как нужно пользователям. Тесты лишь проверяют, что новый функционал уже (до коммита кода) работает или существующий функционал всё ещё (после внесения изменений) работает.
IQ>Имхо бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и конечно же за пределами кода. Что уж тут говорить по поводу тестов.
Это слишком абстрактно. Так не долго дойти до роли человека во Вселенной, смысле жизни, сущности всего.
IQ>И это я еще не беру в рассчет ошибки программера.
Да. Это хорошо решается другими техниками — парное программирование, ревью, написание тестов (по крайней мере некоторых из них) другими людьми.
IQ>·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен. IQ>В вашей фразе кстати бездна философского смысла! (без сарказма) Но в этой реальности бизнес не знает о юнит тестах)))
Мне просто довелось в такой команде поработать — одно удовольствие.
Бизнесу об этом и не надо знать, он просто может доверять девам, что они знают что делают для обеспечения качества.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[20]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>Увы, бизнес функционал может быть вообще не связан с написанным кодом, например если аналитики "сработали плохо". Бизнес функционала вообще (части бизнес функционала) может вообще не быть ))) т.к. ее планирую стартовать после релиза проекта. Ну и что хуже всего бизнес функционал скорее всего измениться в процессе эксплуатации проекта, этого не будет в коде соотв. этого не будет в тестах. ·>Непонятно. В этом случае пользователи будут ворчать, что программа делает не то, что надо. Конечно, тесты не могут гарантировать, что реализованный функционал работает как нужно пользователям. Тесты лишь проверяют, что новый функционал уже (до коммита кода) работает или существующий функционал всё ещё (после внесения изменений) работает.
Вы все правильно говорите ))) Заказчик всегда будет ворчать, что функционал не работает так как ему надо ))) и пофиг ему на все юнит тесты.
IQ>>Имхо бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и конечно же за пределами кода. Что уж тут говорить по поводу тестов. ·>Это слишком абстрактно. Так не долго дойти до роли человека во Вселенной, смысле жизни, сущности всего.
Возможно... на мой взгляд все предельно конкретно ))) и позволяет формировать верное отношение к вещам, а это имхо залог способности избегать самообмана.
IQ>>·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен. IQ>>В вашей фразе кстати бездна философского смысла! (без сарказма) Но в этой реальности бизнес не знает о юнит тестах))) ·>Мне просто довелось в такой команде поработать — одно удовольствие. ·>Бизнесу об этом и не надо знать, он просто может доверять девам, что они знают что делают для обеспечения качества.
Я не про то. Я намекал на то, что если бизнес на нашел времени сформулировать "тесты" как "валидные кейсы" то очень вероятно, что система ему нафиг не нужна.
Re[21]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, IQuerist, Вы писали:
IQ>·>Непонятно. В этом случае пользователи будут ворчать, что программа делает не то, что надо. Конечно, тесты не могут гарантировать, что реализованный функционал работает как нужно пользователям. Тесты лишь проверяют, что новый функционал уже (до коммита кода) работает или существующий функционал всё ещё (после внесения изменений) работает. IQ>Вы все правильно говорите ))) Заказчик всегда будет ворчать, что функционал не работает так как ему надо ))) и пофиг ему на все юнит тесты.
Заказчику в общем-то на весь код пофиг.
IQ>>>Имхо бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и конечно же за пределами кода. Что уж тут говорить по поводу тестов. IQ>·>Это слишком абстрактно. Так не долго дойти до роли человека во Вселенной, смысле жизни, сущности всего. IQ>Возможно... на мой взгляд все предельно конкретно ))) и позволяет формировать верное отношение к вещам, а это имхо залог способности избегать самообмана.
Если обсуждать техническую реализацию (а тесты это часть её), то нужно опираться на ближайший источник требований — бизнес-требования. А откуда они берутся — не столь важно. Конечно, эти требования могут быть плохо сформулированы или не удовлетворять бизнес-задачам, но это проблема к тестам и вообще написанию кода не имеет никакого отношения.
IQ>>>·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен. IQ>>>В вашей фразе кстати бездна философского смысла! (без сарказма) Но в этой реальности бизнес не знает о юнит тестах))) IQ>·>Мне просто довелось в такой команде поработать — одно удовольствие. IQ>·>Бизнесу об этом и не надо знать, он просто может доверять девам, что они знают что делают для обеспечения качества. IQ>Я не про то. Я намекал на то, что если бизнес на нашел времени сформулировать "тесты" как "валидные кейсы" то очень вероятно, что система ему нафиг не нужна.
Бизнес формулирует не тесты, а бизнес-требования в виде сценариев/историй, описывая неформальным документом. Это уже задача разработчиков формализовать требования в виде кода.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
