Как бы вы спроектировали настольное приложение на C# 3.0
Я создал простое настольное приложение на C# 3.0, чтобы изучить C#, wpf и .Net 3.5. Мое приложение, по сути, считывает данные из файла csv и сохраняет их в базе данных CE SQL-сервера. Я использую sqlmetal для генерации кода ORM для базы данных. Моя первая итерация этого приложения чертовски уродлива, и я занимаюсь ее рефакторингом.
Это подводит меня к моему вопросу. Как бы вы спроектировали настольное приложение базы данных на C#? Какие лучшие практики?
Вы создаете уровень абстракции базы данных (DAL), который использует код, сгенерированный sqlmetal? Или сгенерированный код является достаточно абстракцией?
Если вы используете шаблон DAL, вы делаете его одноэлементным или статическим членом? Используете ли вы шаблон View-Model-ModelView с шаблоном DAL?
Прошу прощения, если это кажется давно открытым вопросом, но в последнее время я много думал об этом. Я вижу много примеров того, как создать многоуровневое корпоративное приложение на C#, но не так много примеров архитектуры автономных настольных приложений.
Ответы 5
Прежде чем что-либо создавать, вы должны определить требования для своего приложения. Это распространенная ошибка начинающих разработчиков - они начинают писать код раньше, чем думают о том, как он будет работать. Мой совет - попытаться описать некоторые особенности вашего приложения. Это поможет вам почувствовать, как это должно быть реализовано.
Что касается полезных учебных ресурсов, я настоятельно рекомендую вам взглянуть на CompositeWPF, это проект, разработанный специально для обучения разработчиков передовым методам разработки настольных приложений.
Я бы начал с Руководство по составному приложению для WPF (кашель PRISM кашель) от команды Microsoft P&P. Вместе с загрузкой идет отличное справочное приложение, которое является отправной точкой для большей части моей сегодняшней разработки WPF.
Команда DotNetRocks только что опросил Гленн Блок и Брайан Нойес об этом, если вы хотите услышать от них больше.
Более того, Prism не так тяжел, как CAB, если вы вообще знакомы с этим со времен WinForms.
Ответ, как всегда, «зависит от обстоятельств».
Несколько вещей, о которых стоит подумать: Возможно, вы захотите в какой-то момент сделать это толстое клиентское приложение веб-приложением (например). Если это так, вы должны быть уверены, что сохраняете разделение между бизнес-уровнем (и ниже) и презентацией. Самый простой способ сделать это - убедиться, что все вызовы бизнес-логики проходят через какой-либо интерфейс. Более сложный способ - реализовать полную настройку MVC.
Еще одна вещь, которую вы можете рассмотреть, - это сделать уровень доступа к данным независимым от бизнес-логики и пользовательского интерфейса. Под этим я подразумеваю, что все вызовы бизнес-логики в DAL должны быть универсальными: «получить мне эти данные», а не «получить мне эти данные из SQL» или, что еще хуже, «запустить этот оператор SQL». Таким образом, вы можете заменить свой DAL на тот, который обращается к другой базе данных, XML-файлам или даже к чему-то неприятному, например, к плоским файлам.
Одним словом, разделение проблем. Это позволяет вам расти в будущем, добавляя другой пользовательский интерфейс, сегментируя все три области на их собственные уровни или изменяя соответствующую технологию.
Я бы сказал, да, его можно легко структурировать для небольших приложений. Чтобы начать работу, нужно научиться, но, честно говоря, это помогло мне понять WPF лучше, чем попытки начать с нуля. После запуска проекта с CompositeWPF, а затем запуска другого проекта без него, я обнаружил, что пытаюсь дублировать функции CompositeWPF самостоятельно, потому что я пропустил эти функции! :)
Я бы начал с серии Создайте свою собственную кабину Джереми Миллера.
Я был одним из первых приверженцев CAB. Я многому научился, углубившись в эту технологию и прочитав все блоги .NET об архитектуре приложений.
Но недавно у меня была возможность начать новый проект, и вместо использования CAB я выбрал StructureMap и NHibernate и позаимствовал некоторые шаблоны, которые использует Джереми (в частности, его способ обработки агрегации событий). В результате получился действительно упрощенный, отлаженный вручную фреймворк, который делает все, что мне нужно, и мне нравится с ним работать.
Что касается специфики вашего вопроса: я использую репозиторий для доступа к данным. Сначала я написал код ADO.NET, использовал средства чтения данных и сопоставил свои объекты. Но это очень быстро устарело, поэтому я взял NHibernate и был очень доволен. Репозитории используют NHibernate для доступа к данным, и мои потребности в доступе к данным довольно просты в этом конкретном приложении.
У меня есть уровень обслуживания (предоставляемый через WCF, дуплексные каналы), который использует репозитории. Мое приложение в основном клиент-серверное с обновлением в реальном времени (и я знаю, что ваш вопрос касался только клиентов, но я бы использовал те же технологии и шаблоны). О
На стороне клиента я использую MVP с StructureMap для IoC и некоторые очень простые стратегии агрегации событий для межклассовых коммуникаций. Я кодирую интерфейсы практически для всего. Единственное, что я сделал, это позаимствовал у CAB идею гибкого «рабочего пространства» для динамического отображения представлений. Тем не менее, я написал свой собственный интерфейс Workspace и реализовал свои собственные DeckWorkspace и TableWorkspace для использования в моем приложении (это было действительно просто написать).
Многие мои решения в этом последнем приложении были результатом опыта и боли, которые я чувствовал при использовании других фреймворков и инструментов. На этот раз я принял другие решения. Может быть, единственный способ понять, как спроектировать приложение, - это заранее почувствовать боль, сделав это неправильно.