MVVM с WPF, использующим LINQtoSQL в DAL вместе с BLL

Question

Моя цель - иметь приложение, которое использует WPF и имеет трехуровневую архитектуру. Пользовательский интерфейс, BLL и DAL ... Я хотел бы использовать MVVM, но я не уверен, как это работает с 3-уровневой архитектурой или если это что-то совершенно другое. Итак, учитывая это, у меня есть несколько вопросов:

1) LINQtoSQL: я много читал в Интернете, где говорится, что LINQ заменяет ваш DAL, и видел много статей, в которых говорится, что это плохая идея. Я думаю, что это плохая идея, однако, что я здесь вкладываю? Какие типы данных я возвращаю в BLL? IQueryable? ObservableCollection? Понятия не имею.

2) BLL: я бы хотел сделать эту службу запущенной на сервере, чтобы при внесении изменений мне не нужно было повторно развертывать все приложение, мне просто нужно перезапустить службу , Но я не уверен, с чего начать.

3) Я полагаю, что с BLL я не понимаю, как данные проходят через все слои от DAL до Интерфейса.

Я провел много исследований в Интернете и получил кое-что, но я не видел, чтобы кто-нибудь говорил о приложении WPF, использующем MVVM с LINQ в DAL, использующем SQLMetal и BLL, работающем на сервер. Может кто-то указать мне верное направление? или, может быть, книгу, чтобы получить?

Answer 1

Mike

твой вопрос действительно классный, мне это нравится. Во-первых, не стесняйтесь немного поэкспериментировать - каждый проект индивидуален, поэтому нет единого правила, которое бы подходило везде. Вот почему я бы предложил оставить DAL для LINQ 2 SQL. этот замечательный инструмент справится с этим, вам не о чем беспокоиться. Во-вторых, вы упомянули 3-уровневую архитектуру, но почему нет места для модели? Поскольку все модели генерируются автоматически (например, SQLMetal), вам также не нужно беспокоиться о сопоставлениях. Итак, если вам еще не скучно, позвольте мне ответить на все ваши 3 вопроса:

1. Пропустите DAL и внимательно наблюдайте за своим проектом - если у вас есть ощущение, что ему не хватает этого слоя - добавьте его (он будет содержать запросы LINQ2SQL). И вторая часть - вы можете вернуть все, что пожелаете, но для вас будет наиболее удобно использовать IEnumerable <> или IQueryable <>, параметризованный вашими моделями.

2. Моя интуиция подсказывает мне, что вам понадобится WCF - в этом случае вы должны иметь возможность обернуть всю (да, это правда) всю бизнес-логику в хороший Контракт и реализовать, как пожелаете.

3. Это самый простой способ :) Поскольку ваш уровень BLL на самом деле является реализацией какого-либо Контракта (Интерфейса), вы можете спроектировать этот Интерфейс, чтобы предоставить вам все необходимые данные. Например:

Контракт / Интерфейс:

IEnumerable<User> GetTallUsersOver40();
IEnumerable<User> GetShortUsersOver60();
...

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

Я хочу использовать MVVM, что теперь? Ответ проще, чем вы думаете - просто подготовьте свои представления и модели и просто используйте реализацию BLL Contract / Interface.

Пожалуйста, спросите, если у вас есть дополнительные вопросы!

Answer 2

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

1. LINQ to SQL на самом деле довольно хорош в том, что он должен делать - что заменяет ваш DAL. Но не возвращайте IQueriable вверх в ваш BLL, поскольку это позволит (или, по крайней мере, намекнет на возможность) BLL напрямую запросить вашу БД. Вы должны передать объект данных в BLL и позволить ему создать соответствующий бизнес-объект. Также обратите внимание: LINQ сам по себе может использоваться в любом слое (и фактически является одной из лучших функций C #). LINQ to SQL - это механизм, с помощью которого операторы LINQ транслируются в запросы SQL.

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

3. BLL генерирует бизнес-объекты на основе данных, которые он получает от DAL. Чтобы обеспечить хорошее разделение слоев, вы должны использовать разные классы для ваших объектов DAL и BLL. Не создавайте зависимость между уровнем представления и уровнем данных.

Answer 3

Отличный вопрос, я нахожусь на склонах детской кривой обучения WCF / WPF, поэтому я нахожусь с вами в таком же положении. Мои 2 цента:

1. Не попал в Linq to SQL, я в старой школе и привык писать хранимые процедуры и представления. В настоящее время я использую их для заполнения классов DTO - то есть классов без методов, просто свойств для представления данных. Я знаю, что я, вероятно, за кривой на этом.

2. Сделайте свой BLL сервисом WCF - поместите контракт (ы) на обслуживание и контракт (ы) на данные в их собственную сборку, затем вы можете включить это в свой клиент, где они станут вашей моделью или частью ее ,

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

Я пользуюсь книгами О'Рейли «Программирование служб WCF», «Обучение службам WCF и программирование WPF», которые я нахожу довольно хорошими. Я не знаю ни одной книги конкретно о MVVM, но в Интернете есть масса вещей.

Answer 4

Отличный вопрос. Я не думаю, что есть какое-то место, где есть ответы на все вопросы. У меня были очень похожие вопросы, когда мы начинали новый проект. MVVM - это просто шаблон презентации, и он не заботится обо всех деталях, перечисленных вами. Laurent Bugnion имеет хорошую основу, которая также склеивает все вместе.

1. LINQ2SQL - это круто, но с разработчиками VS08 может быть громоздким. Взгляните на http://plinqo.com/ для использования с CodeSmith для генерации DAL, и я думаю, что он будет даже делать BLL с контрактами. Другой вариант генерации - Шаблоны Олега Сыча T4 Одна проблема, с которой мы столкнулись в LINQ2SQL, - это единый текстовый текст. Если вам не нужно быть модульным, это не проблема.

2. Я согласен с тем, что другие говорили о контрактах на данные, и смотрю на то, что может генерировать Plinqo. Это может сэкономить вам много времени.

3. Данные будут работать в объектах как обычно. Как и другие, убедитесь, что вы держите взгляд между всеми слоями, чтобы у вас не было зависимостей.

Когда вы доберетесь до части MVVM, вы откроете новую банку с червями. Я не думаю, что есть много или каких-либо книг о MVVM еще. Это все еще несколько новое увлечение.