Как бы вы разработали настольное приложение в C # 3.0?

Question

Я создал простое настольное приложение на C # 3.0 для изучения C #, wpf и .Net 3.5. Мое приложение по существу считывает данные из файла CSV и сохраняет их в базе данных CE сервера SQL. Я использую sqlmetal для генерации кода ORM для базы данных. Моя первая итерация этого приложения ужасна, и я нахожусь в процессе его рефакторинга.

Что подводит меня к моему вопросу. Как бы вы разработали приложение для настольной базы данных на C #? Каковы лучшие практики?

Создаете ли вы уровень абстракции базы данных (DAL), который использует сгенерированный sqlmetal код? Или сгенерированный код достаточно абстракции?

Если вы используете шаблон DAL, вы делаете его одноэлементным или статическим элементом? Используете ли вы шаблон View-Model-ModelView с шаблоном DAL?

Извиняюсь, если это кажется длинным открытым вопросом, но я в последнее время много размышлял над этим. Я вижу много примеров того, как спроектировать корпоративное n-уровневое приложение на C #, но не так много при разработке автономных приложений для настольных компьютеров.

Answer 1

Я бы начал с Руководства по составным приложениям для WPF ( кашель ПРИЗМА кашель ) от команды Microsoft P & P. С загрузкой приходит отличное справочное приложение, которое является отправной точкой для большинства моих сегодняшних разработок WPF.

Команда DotNetRocks только что взяла интервью Гленн Блок и Брайан Нойес об этом, если вам интересно узнать о них больше.

Даже лучше, Prism не такой тяжелый, как CAB, если вы вообще знакомы с этим со времен WinForms.

Answer 2

Ответ, как всегда, "зависит".

Несколько вещей для размышления: Вы можете захотеть сделать это толстое клиентское приложение веб-приложением (например) в какой-то момент. Если это так, вы должны обязательно разделить бизнес-уровень (и ниже) и презентацию. Самый простой способ сделать это - убедиться, что все вызовы бизнес-логики проходят через какой-то интерфейс. Более сложный способ - реализовать полную настройку MVC.

Еще одна вещь, которую вы можете рассмотреть, - сделать уровень доступа к данным независимым от бизнес-логики и пользовательского интерфейса. Под этим я подразумеваю, что все вызовы из бизнес-логики в DAL должны быть общими «получить мне эти данные», а не «получить эти данные из SQL» или, что еще хуже, «выполнить этот оператор SQL». Таким образом, вы можете заменить свой DAL на другой, который обращается к другой базе данных, XML-файлам или даже к чему-то непристойному, как плоские файлы.

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

Answer 3

Я бы начал с серии Джереми Миллера "Создай свою собственную кабину ".

Я был ранним последователем CAB. Я многому научился, изучая эту технологию и читая все блоги .NET об архитектуре приложений.

Но недавно у меня была возможность начать новый проект, и вместо использования CAB я пошел с StructureMap и NHibernate и позаимствовал некоторые из шаблонов, которые использует Джереми (в частности, его способ обработки агрегации событий). Результатом стал действительно упрощенный фреймворк с ручным управлением, который делает все, что мне нужно, и мне нравится работать с ним.

Что касается специфики вашего вопроса: я использую репозиторий для доступа к данным. Первоначально я написал некоторый код ADO.NET, использовал устройства чтения данных и отображал свои объекты. Но это очень быстро устарело, поэтому я взял NHibernate и был очень доволен. Репозитории используют NHibernate для доступа к данным, и мои потребности в доступе к данным довольно просты в этом конкретном приложении.

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

На стороне клиента я использую MVP с StructureMap для IoC и некоторые очень простые стратегии агрегации событий для межклассовой связи. Я кодирую интерфейсы практически для всего. Единственное, что я сделал, - это позаимствовал у CAB идею гибкого «рабочего пространства» для динамического отображения представлений. Я написал свой собственный интерфейс Workspace и реализовал свои собственные DeckWorkspace и TableWorkspace для использования в моем приложении (это были действительно простые вещи для написания).

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

Answer 4

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

Что касается полезных учебных ресурсов, я настоятельно рекомендую вам взглянуть на CompositeWPF - это проект, разработанный специально для обучения разработчиков передовым методам разработки настольных приложений.

Answer 5

Я бы сказал, что да, он может быть легко структурирован для небольших приложений. Существует тенденция к началу работы, но, честно говоря, это помогло мне лучше понять WPF, чем начинать с нуля. Начав проект с CompositeWPF, а затем запустив другой проект без него, я обнаружил, что пытаюсь дублировать функции CompositeWPF самостоятельно, потому что пропустил эти функции! :)