Подход для приложений CRUD n-уровня в .NET.

Question

Вот действительно действительно супер-основной вопрос.

Скажем, я хотел построить сегодня - приложение CRUD для предприятий в .NET, имеющее n-уровневую архитектуру. Какой подход к доступу к данным следует использовать? Я хочу интероперабельность, поэтому DataSets недоступны (и я полагаю, что это тоже не 2003). Аналогичным образом, рекламируемый метод предоставления RIM-сервисов .NET для предоставления своих функций через дополнительную услугу клиентам, не являющимся Silverlight, для операций обновления не выглядит очень convincing. У меня есть вид был способен сглаживать что-то с Entity Framework, у которой нет поддержки OOB на n-уровневом уровне, и поэтому требовалось много странного материала типа отражения, чтобы имитировать подобие оптимистического параллелизма (example в MSDN Magazine не похоже на то, что он поддерживает оптимистичный параллелизм. I hear это улучшено в EF4, но я немного скептически настроен, и он еще не доступен, кроме того, в CTP).

Итак, что могут сделать люди на своих проектах для корпоративного CRUD с оптимизированным параллелизмом с проверкой обновлений? DataSets? DIY с DTO и лорд знает, сколько работы? И как это работает со связанными данными? Скажем, у меня есть коллекция, связанная с DataGrid, мне нужно прослушать CollectionChanged для изменений? Нужно ли мне сохранять стеки изменений, чтобы я мог сравнивать ПК, если есть отмена? Кажется, кошмар.

И, во-вторых, что, если проверка обновлений для оптимистического параллелизма не была жестким требованием? Что тогда?

Answer 1

Прежде всего, если вы планируете перейти на VS2010 и .NET 4.0 в будущем, я настоятельно рекомендую изучить EF v4.0. Он улучшил DRAMATICALLY, так как EF v1.0 был выпущен, и, на мой взгляд, является сильным соперником против подобных nHibernate и друзей. EF является центральным игроком во многих будущих инициативах Microsoft в отношении данных, поэтому его нельзя игнорировать так же легко, как раньше. Он или любая из более ранних платформ .NET 4.0, которые зависят от него, должны хорошо удовлетворять ваши потребности в CRUD.

Это в стороне, я бы просто удостоверился, что простой подход CRUD лучше всего подходит для бизнес-перспективы . CRUD делает тонны смысла с технической точки зрения, а в небольших приложениях это, как правило, правильный выбор. Но вы использовали термин «предприятие», поэтому мне интересно, если ваше приложение имеет более широкий охват, чем простота CRUD.

Все, что находится за пределами вашей мелкомасштабной компании с общей численностью сотрудников 20-50 или около того, и я бы посмотрел на Domain Driven Design (DDD) и SOA. Если вам нужны такие вещи, как управление параллелизмом и тому подобное, руководители, которые управляют DDD, должны хорошо служить вам. SOA обычно полезен для чрезвычайно больших проектов, в которых у вас есть много групп разработчиков, которые одновременно работают над несколькими проектами, которые должны взаимодействовать друг с другом. Это может быть излишним для ваших нужд, но есть некоторые хорошие принципы, которые могут помочь.