Решил все ж таки начать изучать asp.net mvc, причем прямо с core версии.
Вот по этому руководсту http://metanit.com/sharp/aspnet5/ ибо насколько я понял, пока что лучше просто ничего нет.
Начал делать сайт.
Проблема однако же в том, что все примеры используют Entity Framework, и базу данных.
Но мне нужно чтобы сайт работал через серверную часть, которая в свою очередь, будет взаимодействовать не только с сайтом.

Решил заюзать WCF — все контроллеры сайта завязаны на WCF службу, которая располагается на том же сервере.
Правильный ли это подход?
Нет ли тут каких-то потенциальных сложностей, уязвимостей и так далее?

Ну насколько я понимаю, надо подумать о том чтобы служба не была доступна извне, а также о нагрузке на нее.
Пока что удалось использовать только BasicHttpBinding, остальные к сожалению не работают (возможно пока что) в .net core.
10 тысяч запросов отрабатывает последовательно за 5 секунд. По-моему, неплохо. БД бы сильно тупила, особенно всякие EF

Здравствуйте, vl690001x, Вы писали:

V>Решил все ж таки начать изучать asp.net mvc, причем прямо с core версии.
V>Вот по этому руководсту http://metanit.com/sharp/aspnet5/ ибо насколько я понял, пока что лучше просто ничего нет.
V>Начал делать сайт.
V>Проблема однако же в том, что все примеры используют Entity Framework, и базу данных.
V>Но мне нужно чтобы сайт работал через серверную часть, которая в свою очередь, будет взаимодействовать не только с сайтом.

V>Решил заюзать WCF — все контроллеры сайта завязаны на WCF службу, которая располагается на том же сервере.
V>Правильный ли это подход?
V>Нет ли тут каких-то потенциальных сложностей, уязвимостей и так далее?

V>Ну насколько я понимаю, надо подумать о том чтобы служба не была доступна извне, а также о нагрузке на нее.
V>Пока что удалось использовать только BasicHttpBinding, остальные к сожалению не работают (возможно пока что) в .net core.
V>10 тысяч запросов отрабатывает последовательно за 5 секунд. По-моему, неплохо. БД бы сильно тупила, особенно всякие EF

А смысл, если приделать web-морду к службе, то можно и на прямую, через ajax. Аутентификацию и авторизацию сделать на wcf, web-сервер будет только транслировать запросы, так его будет легче заменить другим, например на php или убрать, если передумали, к тому же все будет в одном месте. Для скорости использовать асинхронные запросы к службе, если служба стоит на том же сервере, то можно вызывать классы службы на прямую, без петли обратной связи по сети. Как то так.

Здравствуйте, Qulac, Вы писали:


Q>А смысл, если приделать web-морду к службе, то можно и на прямую, через ajax. Аутентификацию и авторизацию сделать на wcf, web-сервер будет только транслировать запросы, так его будет легче заменить другим, например на php или убрать, если передумали, к тому же все будет в одном месте. Для скорости использовать асинхронные запросы к службе, если служба стоит на том же сервере, то можно вызывать классы службы на прямую, без петли обратной связи по сети. Как то так.

А как через JS обращаться к серверу написанному на C#? Ведь ajax это подразумевает?
Но вообще меня не особо привлекает такая идея — ведь это MVC, то есть именно контроллеры должны получать инфу с сервера, а не представления? То есть ajax тут как бы не при чем.
На php переходить не планирую. Потому что не знаю его и изучать смысла не вижу.

По идее тут какие-то web api можно использовать.
Просто я так понял, проект web api это проект именно web api, у него своя архитекрута, также mvc. А мне он получается нафиг не нужен, я в свой проект серверный буду еще какой-то веб апи сбоку прикручивать.
Как мне кажется, wcf разумный выбор, просто хочется узнать как принято в таких случаях делать.

Здравствуйте, vl690001x, Вы писали:

V>Здравствуйте, Qulac, Вы писали:


Q>>А смысл, если приделать web-морду к службе, то можно и на прямую, через ajax. Аутентификацию и авторизацию сделать на wcf, web-сервер будет только транслировать запросы, так его будет легче заменить другим, например на php или убрать, если передумали, к тому же все будет в одном месте. Для скорости использовать асинхронные запросы к службе, если служба стоит на том же сервере, то можно вызывать классы службы на прямую, без петли обратной связи по сети. Как то так.

V>А как через JS обращаться к серверу написанному на C#? Ведь ajax это подразумевает?

У Вас BasicHttpBinding, доступ к службе можно получить хоть из браузера и работать через js. Можно добавить к службе конечную точку для работы через ajax: Создание служб WCF AJAX без использования ASP.NET

V>Но вообще меня не особо привлекает такая идея — ведь это MVC, то есть именно контроллеры должны получать инфу с сервера, а не представления? То есть ajax тут как бы не при чем.

V>На php переходить не планирую. Потому что не знаю его и изучать смысла не вижу.

V>По идее тут какие-то web api можно использовать.

Можно использовать web api.

V>Просто я так понял, проект web api это проект именно web api, у него своя архитекрута, также mvc. А мне он получается нафиг не нужен, я в свой проект серверный буду еще какой-то веб апи сбоку прикручивать.
V>Как мне кажется, wcf разумный выбор, просто хочется узнать как принято в таких случаях делать.

Если проблему можно решить просто использовав повторно wcf сервис в web-сервере, то почему так не сделать?

Здравствуйте, vl690001x, Вы писали:

V>Ну насколько я понимаю, надо подумать о том чтобы служба не была доступна извне, а также о нагрузке на нее.
V>Пока что удалось использовать только BasicHttpBinding, остальные к сожалению не работают (возможно пока что) в .net core.
V>10 тысяч запросов отрабатывает последовательно за 5 секунд. По-моему, неплохо. БД бы сильно тупила, особенно всякие EF

WCF это транспорт, а БД это впервую очередь хранения состояния. И вы так можете взять и в легкую заменить одно на другое?

Здравствуйте, TK, Вы писали:

TK>WCF это транспорт, а БД это впервую очередь хранения состояния. И вы так можете взять и в легкую заменить одно на другое?

Ну есть же WCF Data Services

Здравствуйте, AndrewVK, Вы писали:

TK>>WCF это транспорт, а БД это впервую очередь хранения состояния. И вы так можете взять и в легкую заменить одно на другое?

AVK>Ну есть же WCF Data Services

Еще у них и новая версия недавно вышла

Здравствуйте, TK, Вы писали:

TK>Здравствуйте, vl690001x, Вы писали:

V>>Ну насколько я понимаю, надо подумать о том чтобы служба не была доступна извне, а также о нагрузке на нее.
V>>Пока что удалось использовать только BasicHttpBinding, остальные к сожалению не работают (возможно пока что) в .net core.
V>>10 тысяч запросов отрабатывает последовательно за 5 секунд. По-моему, неплохо. БД бы сильно тупила, особенно всякие EF

TK>WCF это транспорт, а БД это впервую очередь хранения состояния. И вы так можете взять и в легкую заменить одно на другое?

Ну понятно что это разные вещи...
Конечно я могу хранить состояние опять же в БД.
Но я так не делаю, у меня хранится в xml файлах все и в моих бинарных форматах. Мне так удобнее, чем мучиться с SQL или ORM всякими, тем более когда я пытался с ними связываться, то меня всегда поражала их удивительная неповоротливость.

Тут дело в другом — в MVC контроллерах вместо работы с БД, и вызова db.SaveChanges(); я просто вызываю методы WCF сервиса.

var result = await SERVER_CONNECTOR.AddUserAsync(model.Login, model.Password, model.Email, 0);

Как-то так.

Здравствуйте, vl690001x, Вы писали:

V>Ну понятно что это разные вещи...
V>Конечно я могу хранить состояние опять же в БД.
V>Но я так не делаю, у меня хранится в xml файлах все и в моих бинарных форматах. Мне так удобнее, чем мучиться с SQL или ORM всякими, тем более когда я пытался с ними связываться, то меня всегда поражала их удивительная неповоротливость.

Посмотрите noSql варианты
V>Тут дело в другом — в MVC контроллерах вместо работы с БД, и вызова db.SaveChanges(); я просто вызываю методы WCF сервиса.

V>

V>var result = await SERVER_CONNECTOR.AddUserAsync(model.Login, model.Password, model.Email, 0);
V>

V>Как-то так.

Ничем не отличается от вызова просто метода без всякого WCF. если служба располагается на том-же сервере — пойдите дальше, расположите ее в том-же процессе — все будет еще быстрее.

Здравствуйте, TK, Вы писали:

TK>Ничем не отличается от вызова просто метода без всякого WCF. если служба располагается на том-же сервере — пойдите дальше, расположите ее в том-же процессе — все будет еще быстрее.

У меня есть 3 проекта.
1. — сайт. (Не могу сейчас показать, к сожалению, по некоторым соображениям, доделаю — обязательно покажу).
2. серверная программа.
3. — куча клиентских программ.

Серверная программа взаимодействует как с сайтом так и с клиентскими программами.
С сайтом — по WCF, с клиентскими программами — по WebSocket

Поэтому, размещать в том же процессе — это значит в процессе сайта, который, напоминаю, ASP.NET CORE.
Как это сделать, я не представляю, да и зачем — непонятно.

Здравствуйте, vl690001x, Вы писали:

V>Здравствуйте, TK, Вы писали:

TK>>Ничем не отличается от вызова просто метода без всякого WCF. если служба располагается на том-же сервере — пойдите дальше, расположите ее в том-же процессе — все будет еще быстрее.

V>У меня есть 3 проекта.
V>1. — сайт. (Не могу сейчас показать, к сожалению, по некоторым соображениям, доделаю — обязательно покажу).
V>2. серверная программа.
V>3. — куча клиентских программ.

V>Серверная программа взаимодействует как с сайтом так и с клиентскими программами.
V>С сайтом — по WCF, с клиентскими программами — по WebSocket

V>Поэтому, размещать в том же процессе — это значит в процессе сайта, который, напоминаю, ASP.NET CORE.
V>Как это сделать, я не представляю, да и зачем — непонятно.

Вам попроще или побыстрее? Создайте пользователя на wcf сервисе для web-сервера. Web-сервер будет аутентифицировать пользователя обрамляясь к wcf-серверу. Быстрее только напрямую передавать токен аутентификации, но это сложнее.

Здравствуйте, vl690001x, Вы писали:

V>У меня есть 3 проекта.
V>1. — сайт. (Не могу сейчас показать, к сожалению, по некоторым соображениям, доделаю — обязательно покажу).
V>2. серверная программа.
V>3. — куча клиентских программ.

V>Серверная программа взаимодействует как с сайтом так и с клиентскими программами.
V>С сайтом — по WCF, с клиентскими программами — по WebSocket

Зачем вам в этой схеме WCF? Одно дело когда есть Legacy софт от которого не избавиться, а другой вариант, когда вы смотрите чем БД заменить..

V>Поэтому, размещать в том же процессе — это значит в процессе сайта, который, напоминаю, ASP.NET CORE.
V>Как это сделать, я не представляю, да и зачем — непонятно.

А WCF вам тут зачем? Разделение слоев можно сделать логически — вводить физические барьеры не обязательно.

Здравствуйте, TK, Вы писали:

TK>Зачем вам в этой схеме WCF? Одно дело когда есть Legacy софт от которого не избавиться, а другой вариант, когда вы смотрите чем БД заменить..

А как можно вызывать методы одного процесса из другого процесса в таком случае?

Здравствуйте, vl690001x, Вы писали:

V>А как можно вызывать методы одного процесса из другого процесса в таком случае?

Подменяешь задачу решением, однако.

Здравствуйте, vl690001x, Вы писали:

TK>>Зачем вам в этой схеме WCF? Одно дело когда есть Legacy софт от которого не избавиться, а другой вариант, когда вы смотрите чем БД заменить..

V>А как можно вызывать методы одного процесса из другого процесса в таком случае?

Тот же WebAPI

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, vl690001x, Вы писали:

V>>А как можно вызывать методы одного процесса из другого процесса в таком случае?

AVK>Подменяешь задачу решением, однако.

Т.е., имеется в в виду что это элементарно?
И как же?

Здравствуйте, vl690001x, Вы писали:

V>>>А как можно вызывать методы одного процесса из другого процесса в таком случае?
AVK>>Подменяешь задачу решением, однако.
V>Т.е., имеется в в виду что это элементарно?

Нет, имеется в виду, что ты подменил задачу решением.

Здравствуйте, TK, Вы писали:

TK>Здравствуйте, vl690001x, Вы писали:

TK>>>Зачем вам в этой схеме WCF? Одно дело когда есть Legacy софт от которого не избавиться, а другой вариант, когда вы смотрите чем БД заменить..

V>>А как можно вызывать методы одного процесса из другого процесса в таком случае?

TK>Тот же WebAPI

Возможно, но я только 2 недели назад взялся за изучение ASP.NET, решил сначала изучить его, а потом уж MVC.
В общем-то конечо, я не спорю что WCF тут сбоку можно сказать прикручен и скорее всего без него можно обойтись, но как именно?
Хотя я уже начал делать через него.
Доделаю, проведу какое-нибудь нагрузочное тестирование и посмотрю что отвалится первым — веб сервер или wcf-служба.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, vl690001x, Вы писали:

V>>>>А как можно вызывать методы одного процесса из другого процесса в таком случае?
AVK>>>Подменяешь задачу решением, однако.
V>>Т.е., имеется в в виду что это элементарно?

AVK>Нет, имеется в виду, что ты подменил задачу решением.

Тогда я не понимаю)

Здравствуйте, vl690001x, Вы писали:

AVK>>Нет, имеется в виду, что ты подменил задачу решением.
V>Тогда я не понимаю)

Чего ты не понимаешь? Того что "вызвать метод в другом процессе" это не задача?

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, vl690001x, Вы писали:

AVK>>>Нет, имеется в виду, что ты подменил задачу решением.
V>>Тогда я не понимаю)

AVK>Чего ты не понимаешь? Того что "вызвать метод в другом процессе" это не задача?

Я так еще не делал.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, vl690001x, Вы писали:

AVK>>>Нет, имеется в виду, что ты подменил задачу решением.
V>>Тогда я не понимаю)

AVK>Чего ты не понимаешь? Того что "вызвать метод в другом процессе" это не задача?

Мы в любом случае вызываем метод в другом процессе, даже при использовании WCF.
Если речь идет об именованных каналах, то в WCF они также есть, хотя в core.net можно использовать пока что только BasicHttpBinding.
Но как быть с типами? Если в серверном процессе методы возвращают сложные типы, то в клиентском они также должны быть, насколько я понимаю, или это вообще не сработает?
В любом случае нужна общая dll, а если у меня серверный процесс на .net 4.5 а клиентский на core.net, это уже как минимум все усложняет.
Кроме того, мне вообще не нравятся общие dll.
Связность слишком сильная, а я считаю что надо избегать связности.
WCF решает эту проблему при помощи прокси-классов, это удобно, достаточно просто обновить метаданные службы.
Прокси классы, правда, не имеют поведения, а только состояние (то есть при кодогенерации методы не создаются), но мне этого достаточно.

Получается, преимущество только в скорости работы, но она меня сейчас устраивает.
В чем я не прав?

Здравствуйте, vl690001x, Вы писали:

V>В чем я не прав?

Нового мне добавить нечего. Ты не прав в том что слишком узко смотришь на проблему и подменяешь проблему заранее заданным решением — работой в стиле RPC с меппингом на классы. В то время как даже в рамках WCF такое необязательно (см., к примеру, WebHttpBinding), да и сам WCF вовсе необязателен — пообщаться с сервером можно и посредством ASP.NET WebAPI (в Core оно слилось в экстазе с остальным), и даже просто написать обычный контроллер ASP.NET MVC с небольшими доработками для обработки ошибок, что с успехом используется на этом сайте.
Но у этого всего немного другая парадигма, которая полностью отсекается твоими вводными.

Здравствуйте, Qulac, Вы писали:
Q>Если проблему можно решить просто использовав повторно wcf сервис в web-сервере, то почему так не сделать?
А если понадобится канал связи с WCF-сервисом защитить, то проблем не возникнет?
А то вот здесь сказано:

Поскольку модель веб-программирования HTTP в WCF не поддерживает протоколы WS-*, единственным способом защитить веб-службы HTTP в WCF является обеспечение доступа к ней через HTTPS с использованием SSL-сертификата.Дополнительные сведения о о настройке SSL с помощью IIS 7.0 см. в разделе

Значит ли это, что взаимодействие по HTTPS без IIS-а организовать не получится?

Здравствуйте, stomsky, Вы писали:

S>Здравствуйте, Qulac, Вы писали:
Q>>Если проблему можно решить просто использовав повторно wcf сервис в web-сервере, то почему так не сделать?
S>А если понадобится канал связи с WCF-сервисом защитить, то проблем не возникнет?
S>А то вот здесь сказано:
S>

Поскольку модель веб-программирования HTTP в WCF не поддерживает протоколы WS-*, единственным способом защитить веб-службы HTTP в WCF является обеспечение доступа к ней через HTTPS с использованием SSL-сертификата.Дополнительные сведения о о настройке SSL с помощью IIS 7.0 см. в разделе

S>Значит ли это, что взаимодействие по HTTPS без IIS-а организовать не получится?

В смысле если хостим сервис как простой win-процесс? Вообще судя по сообщениям в сети у людей разные проблемы возникали в таком случае. У меня тоже были. Лучше хостить на iis, везде полно примеров и нет неожиданностей.

Здравствуйте, Qulac, Вы писали:
Q>В смысле если хостим сервис как простой win-процесс? Вообще судя по сообщениям в сети у людей разные проблемы возникали в таком случае. У меня тоже были. Лучше хостить на iis, везде полно примеров и нет неожиданностей.
За IIS дополнительно денюжку платить надо... А хостить WCF с другим (бесплатным) WEB-сервером (типа "Апача") — это вообще бред
Получается, если без IIS, но с WCF и HTTPS, то получится такой сандвич:
HttpClient (web-браузер какой-нибудь) <-> Web-сервер (Apache, например) <-> WCF-севрвис ...
Красиво, но тяжеловато ...

Здравствуйте, stomsky, Вы писали:

S>За IIS дополнительно денюжку платить надо...

Не всегда. На arubacloud.com, к примеру, разницы в цене нет, кроме самого дешевого плана.

S> А хостить WCF с другим (бесплатным) WEB-сервером (типа "Апача") — это вообще бред
S>Получается, если без IIS, но с WCF и HTTPS, то получится такой сандвич:
S>HttpClient (web-браузер какой-нибудь) <-> Web-сервер (Apache, например) <-> WCF-севрвис ...

И в чем принципиальная разница с бутербродом, где вместо апача IIS?

Здравствуйте, AndrewVK, Вы писали:

S>>За IIS дополнительно денюжку платить надо...
AVK>Не всегда. На arubacloud.com, к примеру, разницы в цене нет, кроме самого дешевого плана.
Я занимаюсь разработкой внутреннего софта. У нас тут выход в инет организован очень хитро через массу прокладок и ДМЗ.
Так что я говорю о возможности развернуть свой web-сервер в интранете.

AVK>И в чем принципиальная разница с бутербродом, где вместо апача IIS?
Развертывание Апача, на сколько я знаю, не требует лицензий, т.е. бесплатно. Разве нет?
Хотя при наличии IIS отпадает потребность в self-hosting WCF (если, конечно, необходимость выделить WCF в отдельный сервис не озвучено явно).

Здравствуйте, stomsky, Вы писали:

AVK>>И в чем принципиальная разница с бутербродом, где вместо апача IIS?
S>Развертывание Апача, на сколько я знаю, не требует лицензий, т.е. бесплатно. Разве нет?

IIS тоже. И я так и не понял при чем тут бутерброд.

S>Хотя при наличии IIS отпадает потребность в self-hosting WCF

При наличии апача вроде как тоже. А если у тебя self-hosting, то зачем тебе тогда апач? Поставь какой нибудь nginx в качестве reverse proxy, или вообще пробрось порты напрямую, раз уж у тебя интранет.

Здравствуйте, AndrewVK, Вы писали:

S>>Развертывание Апача, на сколько я знаю, не требует лицензий, т.е. бесплатно. Разве нет?
AVK>IIS тоже
Т.е. если у нас есть лицензионная серверная Windows, то IIS там можно стартовать без дополнительных лицензий?
Я вопросами лицензирования не интересовался никогда, поэтому прошу прощения за возможно дурацкий вопрос...

AVK>И я так и не понял при чем тут бутерброд.
Ну как, если у нас IIS, то можно организовать хостинг WCF-сервиса непосредственно в IIS.
Можно, конечно, и self-hosting для WCF сделать, но это если такое требование будет прописано явно (безопасность, масштабируемость или еще что).
А если мы возьмем другой web-сервер (апач или предложенный ниже nginx), то такой бутерброд придется строить по-любому.

S>>Хотя при наличии IIS отпадает потребность в self-hosting WCF
AVK>При наличии апача вроде как тоже
Да ладно... апача может хостинговать WCF-сервис???
А если апач под чем-нибудь из семейства UNIX-овых запущен будет?

AVK> Поставь какой нибудь nginx в качестве reverse proxy
Ну конкретно апача я взял просто в качестве примера "другого" web-сервера. А так-то можно и любой другой "по вкусу" указать...

Здравствуйте, stomsky, Вы писали:

AVK>>IIS тоже
S>Т.е. если у нас есть лицензионная серверная Windows, то IIS там можно стартовать без дополнительных лицензий?

Верно.

AVK>>И я так и не понял при чем тут бутерброд.
S>Ну как, если у нас IIS, то можно организовать хостинг WCF-сервиса непосредственно в IIS.

Так и в апаче можно, точнее в модуле asp.net.

S>>>Хотя при наличии IIS отпадает потребность в self-hosting WCF
AVK>>При наличии апача вроде как тоже
S>Да ладно... апача может хостинговать WCF-сервис???

Сервис хостит стек asp.net, позднее нужная часть выделена в отдельную инфраструктуру — OWIN. И моно, и кор, насколько мне известно, OWIN поддерживают в полном объеме.

Здравствуйте, stomsky, Вы писали:
AVK>>И в чем принципиальная разница с бутербродом, где вместо апача IIS?
S>Развертывание Апача, на сколько я знаю, не требует лицензий, т.е. бесплатно. Разве нет?
S>Хотя при наличии IIS отпадает потребность в self-hosting WCF (если, конечно, необходимость выделить WCF в отдельный сервис не озвучено явно).

Web server implementations in ASP.NET Core

Здравствуйте, AndrewVK, Вы писали:

S>>Ну как, если у нас IIS, то можно организовать хостинг WCF-сервиса непосредственно в IIS.
AVK>Так и в апаче можно, точнее в модуле asp.net.
Вот об этом я не знал. Спасибо!