А что такое "распределённая трёхзвенка"? Это что-то банальное, типа БД со службами на удалённом сервере, а у клиентов интерфейс? Ну, тогда, вроде, ничего "специального" и "серьёзного" особо читать и не нужно - это обычный вариант. Грубо говоря, читайте "книгу по WCF", книгу по "SQL Server 2008" и т. д. - там же и простые сценарии и примеры приведены.

Тут серьёзность и специальность начинается, когда у вас возникают вопросы масштабирования и прочих запредельных нагрузок, а то, что я выше описал - как раз для нубов.

Я тоже нуб, поэтому мы с вами будем на равных говорить, да.

Насчёт сериализации. Вроде, как-то встречал что-то типа такого этакого... Короче, насколько я понял, EF + сериализация = любовь. И вообще, вроде, любой объект можно в тот же XML сериализовать. В этом тоже ничего "специального" и "серьёзного" нет - просто читайте соответствующие разделы МСДНа про ISerializable и XmlSerializer.

NTierNoobuser7320,

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

Можно идти двумя путями:
1) выбрать что-то самим, фиг знает по каким принципам. Угробить кучу времени. Понять, что "ааа. надо было не это использовать а то". И начать все с нуля. В худшем случае выйдет, что начинать с нуля не выйдет - поддерживаем и развиваем что есть.
Не хочется строить домик из соломы. А потом выяснить, что надо было из кирпича.

2) Спросить у тех, кто уже знает. Выбрать хотя бы правильные технологии - опыт дело наживное. Даже если будут ошибки, но если база (технологии) выбраны правильно изначально, то ошибки то не проблема исправить.
У вас нет конкретики - что за сервис и что он будет делать. Для простых сервисов подходят простые решения и вам достаточно книжек, что я выше написал. А все специальные сервисы специально затачиваются и "правильные технологии" тут у каждого свои и никто бесплатно не будет вам в подробностях рассказывать, "как поднять свой Фейсбук" - только общие схемы, которые вы и так сможете легко найти в Интернете.

Я бы на вашем месте сделал какой-то работающий вариант "по книжкам", а потом смотрел на узкие и проблемные места и задавал уже конкретные вопросы. Всё равно в конечном счёте придётся всё переделать, когда опыта наберётесь, как какому-нибудь Цукербергу. (Думаете, он свой Фейсбук сейчас в том же виде держит, что и в момент релиза? Наверняка он нанял профи и они весь его говнокод выкинули, а сам он только со стороны смотрит и дивится "ого! сам бы я так никогда не смог бы!")

МСУАлексей Кпропущено...

пропущено...
Рядовому участнику поручена разработка архитектуры системы?

+1 хрень полная, похоже на тонкий троллинг
Почему? Я вот тоже такой. Может, народ поучиться хочет, а никто их в команду профи не берёт - все хотят сразу опыт и чтобы не лажал. Есть такое понятие "команда молодых разработчиков". Это у вас там в московиях всякие майкрософты спецкурсы организуют и потом к себе на работу берут сначала стажёрами, а потом и полноценно. А у нас тут в лаптях ходят и вообще.

NTierNoobnetivan1. Wcf полюбому. Сразу подумайте о безопасности (сертификаты и https как информация для размышления). netTcp производительнее,но я использовал его в интранете.
2. Хранимые процедуры, Ef, Linq и тд. Пох. Главное чтобы этот слой БЫЛ. Ваш сервис должен вызывать что-то типа _superEntityDal.GetSuperData(int id ... ).Это мое решительное имхо. По поводу процедур ща тут начнется - не слушайте.Если они вам нужны - используйте, никто от этого не умер.
3. Что такое подмены? Mock? Используйте интерфейсы в DAL через DI и не будет таких проблем.
4. хз
ЗЫ тут уже говорили, подумайте над веб-интерфейсом.
ЗЫ2 еще раз подумайте о безопасности.

1 Я не понял. Так вы НЕ использовали NetTcp ?
Что рекомендуете использовать то, HTTPS, или TCP ?

2. Т.е. у сервера должна быть функция "ДайИнфуПоСущности(АйДиТакойТо)". И он что должен вернуть ? Типизированный датасет или что ?

3. В идеале, думаю убедить команду Unit Testing по максимуму. Моки, стабы. Все по взрослому-пусть опыт растет :) Книга "Art of Unit Testing in Net" прочитана.

_. Что значит "подумать над веб интерфейсом" ? ASp.Net MVC что ли ? Или что имеется ввиду. Я подумаю конечно. Очень даже велики шансы, что если дело стоящее, то будет так, как вы порекомендуете ! Я же говорил, сейчас все на нулевом этапе - и идеи только приветствуются.

1. Да используйте хотя бы что-нибудь для начала. А там сами разберётесь, что вам конкретно нужно.

2. Да хоть по сущности, хоть как. Хотите, ХМЛ возвращайте, а хотите - типизированное нечто. Что там вам лучше по ситуации. Потом переделаете, если что.

3. Книги читать "про запас", без применения тут же - только в качестве обзора, "по диагонали". Всё равно в голове почти ничего не останется. И не пойму, чем вам МСсовские тесты не угодил для начального варианта?

4. Вам ХТМЛ предлагают, потому что он кроссплатформенный. Если у вас железно будут клиенты на Виндовс сидеть с нужным вам Дотнетом, то проще WPF выбрать. В крайнем случае, фронт-энд переделать сможете всегда.

автор1) выбрать что-то самим, фиг знает по каким принципам. Угробить кучу времени. Понять, что "ааа. надо было не это использовать а то". И начать все с нуля. В худшем случае выйдет, что начинать с нуля не выйдет - поддерживаем и развиваем что есть.
Не хочется строить домик из соломы. А потом выяснить, что надо было из кирпича.

2) Спросить у тех, кто уже знает. Выбрать хотя бы правильные технологии - опыт дело наживное. Даже если будут ошибки, но если база (технологии) выбраны правильно изначально, то ошибки то не проблема исправить.
Пишите модульно, по слоям, чтобы можно было переписать потом части, не трогая другие части.


Вообще, идеи "сделать сразу всё как надо" и "молодые разработчики" несовместимы. Только если повезёт. Так что всё равно придётся много переписывать. Да это и лучше - опыт именно из этого приходит, а не когда "всё сразу и как надо".

Алексей Кuser7320Почему? Я вот тоже такой. Может, народ поучиться хочет, а никто их в команду профи не берёт - все хотят сразу опыт и чтобы не лажал. Есть такое понятие "команда молодых разработчиков". Это у вас там в московиях всякие майкрософты спецкурсы организуют и потом к себе на работу берут сначала стажёрами, а потом и полноценно. А у нас тут в лаптях ходят и вообще.Это следствие бездарной кадровой политики. В команде должен быть как минимум один опытный разработчик, который всем всё расскажет, покажет, разработает архитектуру.
Ну, тогда вариант отдать архитектуру на аутсорс под конкретные требования, а потом делать по готовому сценарию. Разве так не делают?