К удаленному или не удаленному? - PullRequest
4 голосов
/ 16 февраля 2011

Для удаленного или не для удаленного?

Простите, если моя терминология неверна на 100%.

После многих лет разработки программного обеспечения (всех приложений для Windows) для небольших компаний янедавно вылез из-под моей скалы и обнаружил концепцию Remoting и / или WCF.Во всех проектах, над которыми я работал в прошлом, каждая клиентская машина всегда подключалась напрямую к серверу базы данных.После прочтения «Microsoft .Net: Архитектура приложений для предприятия» мне недавно пришло в голову, что может иметь больше смысла выставлять наши бизнес-объекты как объекты POCO через WCF, чтобы нашему клиентскому приложению не требовалось устанавливать клиентское программное обеспечение базы данных.на каждой машине (все, что идет с этим, как другая пользовательская лицензия БД на машину).Наше клиентское приложение должно было бы подключиться только к нашей службе WCF, которая, возможно, выставляет «Сервисный уровень» в качестве оболочки для наших бизнес-объектов.

Я сумасшедший или это распространенный подход в распределенных приложениях?

И, кроме того, какое решение ORM может быть нацелено на базу данных и создавать DAL и бизнес-объекты, которые затем могут быть представлены через WCF?

Я также не могу полностью понять, как ленивая загрузкабудет работать в этом сценарии ...

Спасибо, Джонатан

Ответы [ 2 ]

2 голосов
/ 16 февраля 2011

SOA не стоит на месте. Стандартный .NET Remoting с использованием MOA (Message-Oriented Architecture) - это путь!

1 голос
/ 16 февраля 2011

Я собираюсь оставить вопрос ORM для других и ответить только на часть вопроса, спрашивая, является ли это общим подходом.

Это общий подход, называемый SOA (сервис-ориентированная архитектура). Это имеет много преимуществ, а также подводных камней. Все это было несколько лет назад, и теперь оно все еще широко используется, но уровень возбуждения упал.

Тем не менее, в Интернете есть тонны ресурсов для исследования этого. Самая большая выгода заключается в том, чтобы думать заранее, потому что у разных людей разные представления о том, как следует внедрять SOA и что это значит. Кроме того, кроссплатформенные обещания на практике сложнее выполнить, чем люди изначально надеялись. (попробуйте, например, вызвать .NET Web-сервисы из Java. Это можно сделать, но с обеих сторон есть работа, чтобы заставить его работать.) Поэтому, если вам когда-либо нужно беспокоиться о кроссплатформенной совместимости, изучите "SOA". Кроссплатформенная совместимость ", прежде чем стать слишком глубоким. Вам лучше научиться делать это правильно, чтобы потом вас не застали врасплох, и вам не придется заново создавать набор служб, изначально предназначенных для клиентов .NET, которым теперь нужны клиенты Java (например, для приложений для смартфонов). ).

Мы совершили эту ошибку сами и в итоге нам пришлось заново создавать тонну веб-сервисов, когда мы начали разрабатывать сервисы, которые должны были использоваться клиентами Android / Blackberry. Учитывая то, как индустрия все больше ориентируется на разработку смартфонов, получение этого прямо сейчас сэкономит вам массу работы.

...