Структурирование winforms решение C#
Измените последний оператор else на read.next (), и ваш код будет выполнен. Вы просто хотите получить один строковый ответ, поэтому нет необходимости извлекать всю строку из сканера:
else {
System.out.println("Would you like the angles in degrees or radians? (D/R): ");
String newResponse = read.next();//Change to read.next()
System.out.println("Your new response was " + newResponse); //Psuedo code to see if the output is correct.
}
Вот ваша последняя строка вывода:
Would you like the angles in degrees or radians? (D/R):
D
Your new response was D
4 ответа
На самом деле я думаю, что у Вас есть вещи немного прочь от традиционной многоуровневой архитектуры. Обычно, модели Ваших данных, что Ваше приложение продолжает работать, были бы сохранены в бизнес-слое, наряду с кодом для работы на них. Ваш слой данных имел бы и модели данных Вашей платформы персистентности и код для взаимодействия с той платформой. Я думаю, что это могло бы быть источником беспорядка между предложенными местоположениями Ваших классов и Вашей реакции на него на основе Ваших комментариев.
С той точки зрения что-либо, что получает или приносит, было бы обязательно расположено в Вашем слое данных - это получает доступ к данным в персистентном устройстве хранения данных. Что это получает, в конечном счете преобразовываются в бизнес-расположенные на слое объекты, на которые воздействует Ваша бизнес-логика. Вещи, концептуальные модели - как таблица заказов - или бизнес-действия принадлежат бизнес-слоя. Я согласился бы с @Adron с, возможно, тот же беспорядок о том, куда (3) идет в зависимости от того, каково это на самом деле.
Более конкретно:
- Пользовательские настройки являются бизнес-объектами, вещью, которая получает их, является расположенный на слое объект данных.
- Статические данные отображаются на бизнес-объекте (таблица или представление или что-то), вещью, которая получает доступ к внешнему серверу, является расположенный на слое объект данных.
- Пользовательское право является бизнес-объектом, вещью, которая получает его, является расположенный на слое объект данных.
- Таблица Заказов является бизнес-объектом
- Пользование электронной почтой является деловой активностью, таким образом, вещь, что почтовые люди являются бизнес-объектом
[РЕДАКТИРОВАНИЕ] Моя обобщенная 3-уровневая Архитектура для (простых) веб-приложений
DataAccessLayer
Это включало бы мой TableAdapters и DataTables со строгим контролем типов и Фабрики, которые превращают строки моего DataTables в бизнес-объекты в pre-LINQ проектах. Используя LINQ это включало бы мой DataContext, и разработчик генерировал объекты LINQ.
BusinessLayer
Это включало бы любую бизнес-логику, включая проверку и безопасность. В pre-LINQ они были бы моими бизнес-объектами и любыми другими классами, которые реализуют логику приложения. Используя LINQ это частичные реализации класса моих объектов LINQ для реализации безопасности и проверки наряду с любыми другими классами для реализации бизнес-логики.
Презентация
Это мои веб-формы - в основном UI приложения. Я действительно включаю часть логики проверки в формах как оптимизация, хотя они также проверены в BL. Это также включало бы любые пользовательские элементы управления.
Примечание: Это - логическая структура. Структура проекта обычно зеркально отражает это, но существуют некоторые случаи, как соединения с веб-сервисами, которые могут быть непосредственно включены в веб-проект даже при том, что логически компоненты находятся действительно в BL/DAL.
Примечание: Я буду, вероятно, перемещаться в MVC по 3-уровневому однажды ASP.NET, MVC работает. Я сделал некоторые персональные проекты в Ruby/направляющих, и мне действительно нравится парадигма MVC за веб-приложения.
Вы указали то Приложение. Данные должны содержать только структуры данных и интерфейсы, никакой код реализации, который прекрасен, если Вы хотите сделать это, но это оставляет Вас с нигде не поместить Ваш код доступа к базе данных кроме Вашего Приложения. Блок BusinessLogic.
Возможно, действительно необходимо переименовать Приложение. Данные к Приложению. Модель (или что-то подобное), и имеет новое Приложение. Блок DataAccess, который говорит с базой данных (возможно, реализующий шаблон Репозитория). Сделав это, я разделил бы вещи как это:
- Приложение. DataAccess
- Приложение. DataAccess
- Приложение. DataAccess
- Приложение. Модель
- Приложение. BusinessLogic
- -> Приложение. Данные
- -> Приложение. Данные
- -> Приложение. BusinessLogic или Приложение. Данные - не уверенный точно, что это означает.
- -> Приложение. BusinessLogic
- -> Приложение. BusinessLogic
Я, вероятно, пошел бы с
- Данные
- Данные
- Данные, хотя я не совсем уверен, что делает класс
- Данные
- BusinessLogic