Linq To SQL, веб-сервисы, веб-сайты - планирование всего этого

Question

Несколько «частей» (приложение WinForms для примера) моего проекта используют DAL, который я кодировал на основе L2SQL.Я хотел бы добавить несколько WebApps в микс, но проблема в том, что DAL «предлагает» гораздо больше данных, чем нужно WebApp.Намного больше.

Было бы хорошо, если бы я обернул данные, которые нужны веб-сайтам, в веб-сервис, и вместо того, чтобы веб-сайт напрямую подключался к DAL, он проходил бы через веб-сервис, который, в свою очередь,получить доступ к DAL?

Я чувствую, что это добавит много накладных расходов, но с другой стороны, мне определенно не нравится ощущение, что у WebApp есть «возможности» доступа к гораздо большему количеству данных.чем они на самом деле нужно.

Любой вклад будет принята с благодарностью.Большое спасибо за помощь.

Answer 1

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

Если вы планируете в конечном итоге создавать различные интерфейсы (скажем, веб-интерфейс и интерфейс WPF или Silverlight), то веб-службы имеют большой смысл, поскольку они предоставляют общую базу данных для создания и могут быть доступны через ярусы.

Answer 2

Если бы ваш уровень доступа к данным извлекал все данные как IQueryable, то вы могли бы запрашивать ваш DAL и более точно анализировать ваши вызовы БД.1004 * Я писал на уровнях репозитория и сервиса, используя Linq to SQL.Моя статья построена на MVC, но концепция слоев Repository и Service будет прекрасно работать с WebForms, WinForms, Web Services и т.д.AsQueryable в результате чего вы дожидаетесь последнего возможного момента для фактической фиксации запроса данных.

Ваша структура будет выглядеть примерно такзвонки на основе приложения, для которого вы разрабатываете.Это обеспечивает большую безопасность и конфигурацию для каждого приложения, в то же время поддерживая полный репозиторий, который не нужно изменять, пока вы не поменяете свой ORM (если вы когда-нибудь решите, что вам нужно поменять свой ORM)

Answer 3

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

1. Если модель предметной области меняется, необходимо изменить только сопоставление с DTO. Вы можете изолировать приложение-потребитель от этих изменений.
2. Меньше данных по проводам
3. Вы можете изолировать свои приложения от реализации DAL.
4. Вы можете предоставлять разные сервисы (возможно, разные DTO) для разных приложений, если необходимо ограничить, какие части объектной модели должны быть представлены.

Answer 4

Нет ничего плохого в том, чтобы иметь больше, чем нужно в этом случае. Весь клиентский профиль .NET 4 содержит более 50 МБ сборок, классов и т. Д. Я мог бы использовать 5% его за всю свою карьеру. Это не значит, что я не ценю, чтобы все это было доступно на тот случай, если оно мне понадобится.

Если вы планируете предоставлять DAL разработчикам, которые не должны иметь доступа к частям данных, напишите оболочку или получите новый DAL. Я бы избегал маршрута обслуживания, если вы не уверены, что сможете справиться с накладными расходами.