Linq to SQL ORM 3-слойный вопрос

Question

Я разрабатываю эту систему управления персоналом (для настольных компьютеров) для организации среднего размера. Дело в том, что я разработал все таблицы и планировал использовать O / RM в VS2008 для генерации классов сущностей (это первый раз, когда я работаю с OR / M; фактически это мой первый «большой» проект). ) Я хотел сделать приложение с 3 слоями (один из программистов компании предложил не 3, а 4 или 5 слоев), но после прочтения довольно большого количества записей в блоге и множества вопросов здесь я понял, что это не совсем это легко сделать с помощью LINQ to SQL из-за того, как работает текст данных и насколько сложно передавать объекты между слоями с помощью LINQ to SQL.

Вероятно, я просто буду использовать классы сущностей, сгенерированные ORM VS2008, и добавлю любую логику проверки и бизнес-операций в частичные классы. Но это будет 2 слоя или нет? Приложение будет использоваться примерно 10 пользователями, поэтому я не думаю, что двухслойный подход - большая проблема на данный момент.

В будущем будет разработан веб-интерфейс, чтобы кандидаты могли подать заявку на работу в Интернете. Я хочу развивать его как можно более масштабируемым. Но правда в том, что у меня не так много времени, чтобы тратить время на принятие решения, а иногда - хехе.

Сказав все это, я должен просто использовать сущности, сгенерированные VSM8 ORM?

Так что любое предложение или идея будет принята с благодарностью. Спасибо.

Answer 1

Это звучит как опасный путь - сначала создать таблицы, затем домен и, наконец, GUI. Я должен признать, что я не эксперт ORM, но сгенерированные классы, которые я видел, больше похожи на объекты данных, чем на классы. Я бы сказал, что вам нужен еще один слой, чтобы вся логика перестала появляться в GUI).

Answer 2

Вы много пережевываете свою линию вопросов здесь. (Там где-то спрятан конкретный вопрос?)

С уровнями, я полагаю, вы имеете в виду физические границы, то есть приложение, сервер приложений / SOA / WCF, слой данных, который находится на сервере SOA, и базу данных где-то.

Проектирование на будущее может показаться хорошей идеей, но ОБЯЗАТЕЛЬНО убедитесь, что во всех этих слоях где-то в будущем будет необходимость. По сути, вам не нужен подход, основанный на WCF / SOA, если вы в какой-то момент не выставляете свое приложение через Интернет. Веб-интерфейс может решить эту проблему во многих случаях.

Я не говорю, что вам вообще не понадобятся эти слои, но вы можете и не захотеть. Если вы действительно, швы - ваш друг. Вы должны сделать «точки разреза», где вы можете определить свои границы. Я обычно использую шаблон репозитория для диверсификации методологий доступа к данным, а также использую простые объекты (POCO) и интерфейсы, которые сохраняются с помощью таких технологий, как NHibernate. Использование POCO также значительно облегчает передачу этих объектов по проводам на более позднем этапе, как в отдельности, так и в части сообщений.

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