Алексей ну а что тут думать - раз связей нет и не может быть, т.к. разные базы, то и ORM-маппинги можно отдельные сделать, а сопоставлять объекты вручную, в коде. Т.е. оставить идектификатор подразделения обычным int-ом в публичном свойстве, а объект поздразделения вытаскивать из другой сессии с базой справочников. Тем более проще, если вы справочники менять не намерены.
Если переживаете за сохранность данных в сторонних базах, попросите того, у кого есть админ. доступ дать вам пользователя БД с правами только на чтение. Идеальный вариант в плане не напортачить. По большому счету, хороший администратор и должен вам выдать именно такой доступ к базе справочников.
> Я захожу через удаленный рабочий стол на удаленную машину
Очень странно, видимо приложения кривые. Обычно все окна закидываются на основной монитор, у меня точно такая же ситуация как у вас, и проблем нет. Это конечно если речь идет об RDP - у TeamViewer например есть переключение мониторов.
programmerjava так а куда проще?) Спросите ее, ей же нравится когда публичные люди красиво говорят?) Вот скажите, что программа - это "речь" программиста. Да, конечно аналогия не стопроцентная, но то что мысли выражаются в коде - точнее не скажешь.
pygame
> Под него есть генераторы кода?
Пользовался генератором под ASP.Net WebAPI, вполне выполняет свою функцию: в студию ставится Extension, в webapi проект добавляется raml-файл, по нему генерится код контроллеров на шарпе, содержащий методы и атрибуты с маршрутами из вашего API. Эти методы-заглушки вызывают парные им методы, где вы уже пишете конкретную реализацию.
Почему это удобно? Потому что RAML-файл становится основным документом-договором по API. Т.к. из него генерится код, то при изменении его описания при сборке webapi-проекта сразу же всплывают все проблемы, связанные с изменением "договора", например нереализованные экшены контроллера, или изменившийся список параметров. Лично я очень люблю, когда инструмент мне гарантированно скажет хотя бы о некоторых проблемах (поэтому и пользуюсь в основном компилируемыми языками). При этом, тут же в RAML файле вы пишете описание экшенов и передаваемых в обе стороны параметров и данных, можно даже JSON-схему для запросов и ответов указывать. То есть по тому же самому RAML-файлу вы можете сгенерить и доки для чтения человеком.
Поэтому вывод очень простой: эти инструменты хороши, потому что а) они решают важнейшую проблему всей информатики - синхронизацию информации об одном и том же объекте в нескольких местах. Вместо рукописных доков и кода, за соответствием которых надо следить, у вас остается ОДИН авторитетный источник и для человеческой документации, и для "компиляторской" документации в виде кода для клиента и сервера. б) они решают проблему стандартизации. Очевидно, что для текстового человеческого описания без всякого синтаксиса невозможно сгенерить,например, тестовый сервис-заглушку, или клиент-заглушку. в) добавляя стандартизацию, они добавляют семантику, в том числе и в документацию. Для тех же целей создаются и другие форматы, например DocBook. Только в докбуке вы оперируете понятиями "параграф", "глава" и "фрагмент кода", а тут сущности еще более высокоуровневые: "описание экшена", "описание ресурса" и т.д.
Разумеется, возникает стандартная дилемма: усложнить процесс разработки и пользоваться подобными тулзами, или не усложнять, и писать все на Markdown и не заморачиваться. Это каждый решает сам в каждом отдельном проекте.
В какой кодировке файл с вопросами? В какой кодировке (и самое главное - как) вы выводите эти строки? И не надо string* пожалуйста, это ж C++, ну заведите список или вектор и передайте его в функцию по ссылке.
Happy Marmoset кто говорит и кто подразумевает? Когда говорят Entity Framework и Hibernate, подразумевают ORM, но не подразумевают ActiveRecord. А вообще в общем списке у Фаулера, ссылку на который я дал, есть и то и другое
> i = 33554433
Я не понял - вы уверены, что вам столько надо, или нет? В том смысле что список res тоже будет немалым, может действительно другой алгоритм нужен? Ну или не заю, yield return какой-нибудь.
DK да, кстати, https я не случайно указал - если API предполагают авторизацию (а таких подавляющее большинство), то HTTP по большому счету не пригоден для использования в этом случае.
DK
> или еще есть другие способы, кроме тех которые соединяются на прямую с БД?
по сути вопрос в том, какое API использовать. Когда соединяются напрямую с сервером БД - условно говоря используют API сервере БД - языки запросов. Когда соединяются с веб-сервисом, то его API тоже может быть разным. Может быть узким, позволяющим выполнить только конкретные операции (добавить пост/удалить пост/получить все посты до указанной даты), или же более широким, вроде OData (https://en.wikipedia.org/wiki/Open_Data_Protocol), который имеет даже синтаксис запросов наподобие SQL (но не эквивалентный).
> usr=user001&psw=pass
почитайте про аутентификацию в веб-приложениях. Вы сейчас делаете большой велосипед. Чтобы не нарваться на массу неприятностей, почитайте об этом в книгах. И изучите механизмы аутентификации/сессий в той платформе, которую используете. Реализовать это и c ServiceStack и со стандартным Web API можно, это типовые задачи.
