Нас двое я и шеф. Шеф шарит в делфи, но щас занят другими делами. Дал задание и свалил.
Надо написать серверную прогу, которая будет клиентским прогам слать данные, которые будет считывать с базы данных

С базами данных и их подключению я разобрался. А как сделать так чтоб сервер "ждал" подключения клиента.

Походил по форуму, толком для себя ничего не уяснил.
ХОтел было начать писать MFC приложение. Только мне нужно будет потом в клиентской проге в реальном времени отображать постоянно обновляемую таблицу базы данных(диспетчерская такси). На С-шарпе это просто - есть контрол DataGridView. В MFC такого не нашел(может плохо искал). И вообще хочу в будущем на C# писать. Поэтому отдал предпочтение С#.
Подскажите есть аналог СОКЕТА в С#. Или какой другой вариант построения взаимодействия клиент-сервер. Слыхал предлагают юзать АСП.НЕТ. Только нет времени изучать.


Это сообщение отредактировал(а) CityAC - 18.9.2007, 16:53

Сокет, он и в C# сокет: System.Net.Sockets.Socket.
Но проще клиент-серверное взаимодействие организовать с помощью Remoting или Веб-сервисов. Remoting предпочтительнее при "сильном" взаимодействии, и только приложений на платформе .NET. При помощи веб-сервисов ASP.NET, или WCF можно организовывать взаимодействие между клиентами, написанных на разных языках.

Так новое слово  - remoting. Интересно, что в Троелсоне про это почти ничего не написано. Встречается в книге всего два раза.
С чем его едят? 
И одно уточнение, клиенты с сервером будут общаться по локалке.
Если можно, какие нибудь куски кода, чтоб было понятнее

гм. с помощью remoting - не уверен, что проще.
С помощью веб-вервисов - уверен, что не получится. Ограничения уж больно большие на "взаимодействие"...


а именно, в чем предпочтение?

CityAC, на форуме полно примеров. Ты в "Распределенные приложения и сеть" загляни. Тебе туда.
Кстати, кой-какой ремоутинг пример и список книг тут

Ну, зависит от задачи, конечно. Вместо того, чтобы придумывать свой протокол, иногда легче воспользоваться готовым каркасом. 



Я имел в виду более "связанном" взаимодействии. Вот как я это понимаю. Remoting позволяет междоменно и удалённо взаимодействовать объектам CLR. Мы можем использовать все конструкции языка с удалёнными объектами, например, конструкторы, делегаты, обратные вызовы событиями, и так далее. Мы можем использовать любые транспортные протоколы.
В веб-службах же понятие объекта более абстрактно, привязанности к платформе нет. В этом их и преимущество и недостаток .

я могу возразить так:


всегда легче  только "готовый" каркас тянет жрет много и медленно тянет. Потому что он "на все и ко всему готовый", так задумывался.


сокеты тоже. Ты в ремоутинге случайно урлы нигде не указываешь? А при создании сокета?
К тому же как раз сокеты обеспечивают кроссплатформенность, а ремоутинг (да и Web-Servises, по большому счету ) "идут в сад"

как я понял нужно данные гонять с места на место... Тогда упомянутые тобой "страшные фичи" тоже идут в сад   
Кроме того, серилизация и маршаллинг данных в ремоутинге занимают времени и ресурсов поболее, чем потоки байтов. К тому же, напоминаю, база данных участвует. Может даже немалая...

кстати, случайно нашел статью в топик

Это сообщение отредактировал(а) tol05 - 18.9.2007, 21:53

tol05, я не буду спорить, поскольку согласен. Вообще, одно другому не мешает. Хотя, зачастую, и взаимоисключает. Нужно гонять данные -- серелизуем, кидаем в сокет; обеспечиваем  самостоятельно параллельность потоков и так далее. Хотим юзать "фичи" и не хотим париться -- используем карсас, на то он и каркас, ему положено быть более медленным. Если технологии сочиняют, значит они кому-нибудь нужны  
Так или иначе, спасибо за диалог, он позволил мне взглянуть на всё это с другой стороны.