Solution решение может содержать несколько проектов: НОУ ИНТУИТ | Лекция | Язык программирования и среда разработки. Цели курса

НОУ ИНТУИТ | Лекция | Язык программирования и среда разработки. Цели курса

Аннотация: Обзорная лекция, в которой вводятся основные понятия курса, рассматривается среда разработки – Visual Studio 2008 и Framework .Net 3.5. Рассматриваются типы проектов, и строится пример достаточно большого проекта.

Ключевые слова: программный продукт, среда разработки, visual, professional, edition, net, ПО, standard, language, Java, объектный язык, место, LINQ, Интернет, ADO, SQL, динамическая переменная, динамический тип, библиотека FCL, just-in-time compiler, дизассемблер, самодокументирование, нетипизированный указатель, адресная арифметика, unsafe, выбрасывание исключений, Common Type System, совместимые модули, ATL, OPEN, project, create, список, MSDN, пункт, Line, главная страница, язык программирования, шаблон, Windows, Web, интранет, application, интерфейс, class, library, DLL, dynamic linking, консоль, control, browser, USER, custom control, service, empty, библиотека классов fcl, executable file, арифметический тип данных, разложение в ряд, заголовок метода, иррациональное число, пределом числовой последовательности, сходимость ряда, стартовый проект, refactoring, ghz, программирование, CLR

intuit.ru/2010/edi»>Проект к данной лекции Вы можете скачать здесь.

Основной целью этого курса является изучение основ объектного стиля разработки программных проектов. Для программиста, владеющего этими основами, не столь важно, на каком конкретном языке программирования или в какой среде ему необходимо разработать тот или иной программный проект, — на любом языке он будет создавать программный продукт требуемого качества. Тем не менее, у каждого программиста есть свои предпочтения, свой любимый язык и среда разработки.

В этом курсе в качестве языка программирования выбран язык C# и его версия 3.0, в качестве среды разработки программных проектов — Visual Studio 2008, Professional Edition и Framework .Net в версии 3.5.

Язык C#

Язык C# является наиболее известной новинкой в области языков программирования. По сути это язык программирования, созданный уже в 21-м веке. Явившись на свет в недрах Microsoft, он с первых своих шагов получил мощную поддержку. Язык признан международным сообществом. В июне 2006 года Европейской ассоциацией по стандартизации принята уже четвертая версия стандарта этого языка: Standard ECMA-334 C# Language Specifications, 4-th edition — http://www.ecma-international.org/publications/standards/Ecma-334.htm.

Международной ассоциацией по стандартизации эта версия языка узаконена как стандарт ISO/IEC — 23270. Заметим, что первая версия стандарта языка была принята еще в 2001 году. Компиляторы Microsoft строятся в соответствии с международными стандартами языка.

Язык C# является молодым языком и продолжает интенсивно развиваться. Каждая новая версия языка включает принципиально новые свойства. Не стала исключением и версия 3.0, рассматриваемая в данном учебном курсе.

Руководителем группы, создающей язык C#, является сотрудник Microsoft Андреас Хейлсберг. Он был известен в мире программистов задолго до того, как пришел в Microsoft. Хейлсберг входил в число ведущих разработчиков одной из самых популярных сред разработки — Delphi. В Microsoft он участвовал в создании версии языка Java — J++, так что опыта в написании языков и сред программирования ему не занимать. Как отмечал сам Андреас Хейлсберг, C# создавался как язык компонентного программирования, и в этом одно из главных достоинств языка, дающее возможность повторного использования созданных компонентов. Создаваемые компилятором компоненты являются само-документируемыми, помимо программного кода содержат метаинформацию, описывающую компоненты, и поэтому могут выполняться на различных платформах.

Из других важных факторов отметим следующие:

• C# создавался и развивается параллельно с каркасом Framework .Net и в полной мере учитывает все его возможности;
• ru/2010/edi»>C# является полностью объектно-ориентированным языком;
• C# является мощным объектным языком с возможностями наследования и универсализации;
• C# является наследником языка C++. Общий синтаксис, общие операторы языка облегчают переход от языка С++ к C#;
• сохранив основные черты своего родителя, язык стал проще и надежнее;
• благодаря каркасу Framework .Net, ставшему надстройкой над операционной системой, программисты C# получают преимущества работы с виртуальной машиной;
• Framework .Net поддерживает разнообразие типов приложений на C#;
• реализация, сочетающая построение надежного и эффективного кода, является немаловажным фактором, способствующим успеху C#.

intuit.ru/2010/edi»>В каком направлении развивается язык C#? Назовем новинки, появившиеся в версии 3.0.

На первое место я бы поставил возможности создания качественно новых типов проектов на C#. Конечно, новые типы проектов нельзя отнести к новинкам языка C#. Эти возможности предоставляет каркас Framework .Net 3.5 и Visual Studio 2008. Но поскольку язык, среда разработки и каркас среды тесно связаны, то с точки зрения программистов, работающих на C#, возможности построения программных проектов на C# существенно расширились.

Введение в язык инструмента, получившего название LINQ (Language Integrated Query). Сегодня ни один серьезный проект на C# не обходится без обмена данными с внешними источниками данных — базами данных, Интернет и прочими хранилищами. В таких ситуациях приходилось использовать специальные объекты (ADO .Net или их более ранние версии). При работе с ними нужно было применять SQL — специальный язык запросов. Благодаря LINQ язык запросов становится частью языка программирования C#. Тем самым реализована давняя мечта программистов — работать с данными, находящимися в различных внешних источниках, используя средства, принадлежащие языку программирования, не привлекая дополнительные инструментальные средства и языки.

Введение в язык инструментария, характерного для функционального стиля программирования, — лямбда-выражений, анонимных типов и функций. Андреас Хейлсберг полагает, что смесь императивного и функционального стилей программирования упрощает задачи разработчиков, поскольку функциональный стиль позволяет разработчику сказать, что нужно делать, не уточняя, как это должно делаться.

Новые возможности появились при реализации параллелизма в программных проектах.

Будущее С#

Следующая версия языка С# 4.0 должна появиться параллельно с выходом новой версии Visual Studio 2010. Продолжается работа над версией C# 5.0. Можно отметить три основные тенденции в развитии языка — декларативность, динамичность и параллельность. Разработчики пытаются придать языку C# свойства, расширяющие традиционные возможности процедурных языков. Явно заметен тренд к функциональным языкам с их декларативным стилем. Такие свойства появились уже в C# 3.0, в следующих версиях они только расширяются.

В новой версии Visual Studio 2010 должны появиться новые динамические языки программирования: «железный змей» — Iron Python и Iron Ruby. Эти языки проще устроены, во многом из-за того, что не являются строго типизированными и потому не позволяют проводить контроль типов еще на этапе компиляции. В C# 4.0 введена возможность задания динамических переменных, аналогично тому, как это делается в динамических языках.

Параллельные вычисления в ближайшие 5-10 лет станут реальностью повседневной работы программиста. В этом направлении развивается техника. Языки программирования должны поддерживать эту тенденцию.

Компилятор как сервис, программирование на лету, — такие возможности должны появиться в C# 5.0. Можно не сомневаться, что C#-программистам в ближайшие годы скучать не придется.

Visual Studio 2008

Как уже отмечалось, принципиальной новинкой этой версии является возможность построения новых типов программных проектов, что обеспечивается новой версией каркаса Framework .Net 3.5. Если не считать этой важной особенности, то идейно Visual Studio 2008 подобна предыдущим версиям Visual Studio 2005 и Visual Studio 2003.

Рассмотрим основные особенности среды разработки Visual Studio.

Открытость

Среда разработки программных проектов является открытой языковой средой. Это означает, что наряду с языками программирования, включенными в среду фирмой Microsoft — Visual C++ .

Net (с управляемыми расширениями), Visual C# .Net, Visual Basic .Net, — в среду могут добавляться любые языки программирования, компиляторы которых создаются другими фирмами.

Таких расширений среды Visual Studio сделано уже достаточно много, практически они существуют для всех известных языков — Fortran и Cobol, RPG и Component Pascal, Eiffel, Oberon и Smalltalk.

Новостью является то, что Microsoft не включила в Visual Studio 2008 поддержку языка Java. Допустимые в предыдущих версиях проекты на языке J++ в Visual Studio 2008 в настоящее время создавать нельзя, ранее созданные проекты в студии не открываются.

Открытость среды не означает полной свободы. Все разработчики компиляторов при включении нового языка в среду разработки должны следовать определенным ограничениям.

Главное ограничение, которое можно считать и главным достоинством, состоит в том, что все языки, включаемые в среду разработки Visual Studio .Net, должны использовать единый каркас — Framework .Net. Благодаря этому достигаются многие желательные свойства: легкость использования компонентов, разработанных на различных языках; возможность разработки нескольких частей одного приложения на разных языках; возможность бесшовной отладки такого приложения; возможность написать класс на одном языке, а его потомков — на других языках. Единый каркас приводит к сближению языков программирования, позволяя вместе с тем сохранять их индивидуальность и имеющиеся у них достоинства. Преодоление языкового барьера — одна из важнейших задач современного мира. Visual Studio .Net, благодаря единому каркасу, в определенной мере решает эту задачу в мире программистов.

Framework .Net — единый каркас среды разработки приложений

В каркасе Framework . Net можно выделить два основных компонента:

• статический — FCL (Framework Class Library) — библиотеку классов каркаса;
• динамический — CLR (Common Language Runtime) — общеязыковую исполнительную среду.

Библиотека классов FCL — статический компонент каркаса

Понятие каркаса приложений — Framework Applications — появилось достаточно давно, оно широко использовалось еще в четвертой версии Visual Studio. Библиотека классов MFC (Microsoft Foundation Classes) играла роль каркаса приложений Visual C++.

Несмотря на то, что каркас был представлен только статическим компонентом, уже тогда была очевидна его роль в построении приложений. Уже в то время важнейшее значение в библиотеке классов MFC имели классы, задающие архитектуру строящихся приложений. Когда разработчик выбирал один из возможных типов приложения, например, архитектуру Document-View, то в его приложение автоматически встраивались класс Document, задающий структуру документа, и класс View, задающий его визуальное представление. Класс Form и классы, задающие элементы управления, обеспечивали единый интерфейс приложений. Выбирая тип приложения, разработчик изначально получал нужную ему функциональность, поддерживаемую классами каркаса. Библиотека классов поддерживала и традиционные для программистов классы, задающие расширенную систему типов данных, в частности, динамические типы данных — списки, деревья, коллекции, шаблоны.

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

Единство каркаса

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

Встроенные примитивные типы

Важной частью библиотеки FCL стали классы, задающие примитивные типы — те типы, которые считаются встроенными в язык программирования. Типы каркаса покрывают основное множество встроенных типов, встречающихся в языках программирования. Типы языка программирования проецируются на соответствующие типы каркаса. Тип, называемый в языке Visual Basic — Integer, а в языках С++ и C# — int, проецируется на один и тот же тип каркаса — System.Int32. В языке программирования, наряду с «родными» для языка названиями типов, разрешается пользоваться именами типов, принятыми в каркасе. Поэтому, по сути, все языки среды разработки могут пользоваться единой системой встроенных типов, что, конечно, способствует облегчению взаимодействия компонентов, написанных на разных языках.

Структурные типы

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

Архитектура приложений

Существенно расширился набор возможных архитектурных типов построения приложений. Помимо традиционных Windows- и консольных приложений, появилась возможность построения Web-приложений. Большое внимание уделяется возможности создания повторно используемых компонентов — разрешается строить библиотеки классов, библиотеки элементов управления и библиотеки Web-элементов управления. Популярным архитектурным типом являются Web-службы, ставшие сегодня благодаря открытому стандарту одним из основных видов повторно используемых компонентов.

Модульность

intuit.ru/2010/edi»>Число классов библиотеки FCL велико (несколько тысяч), поэтому понадобился способ их структуризации. Логически классы с близкой функциональностью объединяются в группы, называемые пространством имен (Namespace). Основным пространством имен библиотеки FCL является пространство System, содержащее как классы, так и другие вложенные пространства имен. Так, уже упоминавшийся примитивный тип Int32 непосредственно вложен в пространство имен System и его полное имя, включающее имя пространства, — System.Int32.

В пространство System вложен целый ряд других пространств имен. Например, в пространстве System.Collections находятся классы и интерфейсы, поддерживающие работу с коллекциями объектов — списками, очередями, словарями. В пространство System.Collections, в свою очередь, вложено пространство имен Specialized, содержащее классы со специализацией, например, коллекции, элементами которых являются только строки. Пространство System. Windows.Forms содержит классы, используемые при создании Windows-приложений. Класс Form из этого пространства задает форму — окно, заполняемое элементами управления, графикой, обеспечивающее интерактивное взаимодействие с пользователем.

По ходу курса мы будем знакомиться со многими классами библиотеки FCL.

Общеязыковая исполнительная среда CLR — динамический компонент каркаса

Важным шагом в развитии каркаса Framework .Net стало введение динамического компонента каркаса — исполнительной среды CLR. С появлением CLR процесс выполнения приложений стал принципиально другим.

Двухэтапная компиляция. Управляемый модуль и управляемый код

Компиляторы языков программирования, включенные в Visual Studio .Net, создают код на промежуточном языке IL (Intermediate Language) — ассемблерном языке. В результате компиляции проекта, содержащего несколько файлов, создается так называемый управляемый модуль — переносимый исполняемый файл (Portable Executable или PE-файл). Этот файл содержит код на IL и метаданные — всю информацию, необходимую для CLR, чтобы под ее управлением PE-файл мог быть исполнен. Метаданные доступны и конечным пользователям. Классы, входящие в пространство имен Reflection, позволяют извлекать метаинформацию о классах, используемых в проекте. Этот процесс называется отражением. Об атрибутах классов, отображаемых в метаданные PE-файла, мы еще будем говорить неоднократно. В зависимости от выбранного типа проекта, PE-файл может иметь разные уточнения — exe, dll, mod или mdl.

Заметьте, PE-файл, имеющий уточнение exe, хотя и является exe-файлом, но это не обычный исполняемый Windows файл. При его запуске он распознается как PE-файл и передается CLR для обработки. Исполнительная среда начинает работать с кодом, в котором специфика исходного языка программирования исчезла. Код на IL начинает выполняться под управлением CLR (по этой причине код называется управляемым ). Исполнительную среду следует рассматривать как виртуальную IL-машину. Эта машина транслирует «на лету» требуемые для исполнения участки кода в команды реального процессора, который в действительности и выполняет код.

Виртуальная машина

Отделение каркаса от студии явилось естественным шагом. Каркас Framework .Net перестал быть частью студии и стал надстройкой над операционной системой. Теперь компиляция и создание PE модулей на IL отделено от выполнения, и эти процессы могут быть реализованы на разных платформах.

В состав CLR входят трансляторы JIT (Just In Time Compiler), которые и выполняют трансляцию IL в командный код той машины, где установлена и функционирует исполнительная среда CLR. Конечно, в первую очередь Microsoft реализовала CLR и FCL для различных версий Windows, включая Windows 98/Me/NT 4/2000, 32 и 64-разрядные версии Windows XP , Windows Vista и семейство .Net Server. Облегченная версия Framework .Net разработана для операционных систем Windows CE и Palm.

Framework .Net развивается параллельно с развитием языков программирования, среды разработки программных проектов и операционных языков. Версия языка C# 2.0 использовала версию Framework .Net 2.0. Операционная система Windows Vista включила в качестве надстройки Framework .Net 3.0. Язык C# 3.0 и Visual Studio 2008 работают с версией Framework .Net 3.5.

Framework .Net является свободно распространяемой виртуальной машиной. Это существенно расширяет сферу его применения. Производители различных компиляторов и сред разработки программных продуктов предпочитают теперь также транслировать свой код в IL, создавая модули в соответствии со спецификациями CLR. Это обеспечивает возможность выполнения их кода на разных платформах.

Компилятор JIT, входящий в состав CLR, компилирует IL код с учетом особенностей текущей платформы. Благодаря этому создаются высокопроизводительные приложения. Следует отметить, что CLR, работая с IL кодом, выполняет достаточно эффективную оптимизацию и, что не менее важно, защиту кода. Зачастую нецелесообразно выполнять оптимизацию на уровне создания IL кода, она иногда может не улучшить, а ухудшить ситуацию, не давая CLR провести оптимизацию на нижнем уровне, где можно учесть особенности процессора.

Дизассемблер и ассемблер

Для проекта, построенного на C#, иногда полезно провести анализ построенного PE-файла, его IL кода и связанных с ним метаданных. В состав Framework SDK входит дизассемблер — ildasm, выполняющий дизассемблирование PE-файла и показывающий в наглядной форме метаданные и IL код с комментариями. Мы иногда будем пользоваться результатами дизассемблирования. У меня на компьютере кнопка, вызывающая дизассемблер, находится на рабочем столе. Вот путь к папке, в которой обычно находится дизассемблер: C:\Program Files\Microsoft Visual Studio .Net\FrameworkSDK\Bin\ildasm. exe

Профессионалы, предпочитающие работать на низком уровне, могут программировать на языке ассемблера IL. В этом случае в их распоряжении будет вся мощь библиотеки FCL и все возможности CLR. У меня на компьютере путь к папке, где находится ассемблер, следующий: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ildasm.exe

В этом курсе к ассемблеру мы обращаться не будем, упоминаю о нем для полноты картины.

c-sharp/terminology_intro at master · Aleksandra-B/c-sharp · GitHub

Permalink

master

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Go to file

Aleksandra-B Rename test1-terminology to terminology_intro

Latest commit 3917230

Feb 3, 2018 History 1 contributor

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

Show hidden characters

	1. Как в языке C# называют именованную последовательность инструкций 1 из 1 балла
	Метод
	2. Какие утверждения верны? 1 из 1 балла
	Сборка — это как правило результат компиляции проекта
	Solution (решение) может содержать несколько проектов
	В проекте может быть более одного кодового файла
	Разные проекты одного решения могут содержать классы в одном и том же пространстве имён
	3. Что перечисляется в секции References (ссылки) проекта в Visual Studio (или других IDE) 0 из 1 балла
	Сборки, классы которых доступны для использования в кодовых файлах проекта
	4. Каково предназначение инструкции using в начале кодового файла? 1 из 1 балла
	Избавляет программиста от необходимости указывать пространство имён перед именами классов данного пространства имён, сокращая код
	5. Где найти exe-файл — результат компиляции моего проекта 1 из 1 балла
	Скорее всего в подпапке bin/Debug папки вашего проекта
	На самом деле путь можно настроить в свойствах проекта (контекстное меню на проекте)

c# — Каковы преимущества нескольких проектов и одного решения?

спросил 11 лет, 2 месяца назад

Изменено 2 года, 6 месяцев назад

Просмотрено 49 тысяч раз

Когда я работал на предприятии, мы использовали в решении несколько проектов — проекты пользовательского интерфейса, бизнес-логики, доступа к данным, базы данных и печати. Теперь я нахожусь на новом предприятии, и менеджер говорит мне, что мне не нужно создавать все эти проекты, но я должен сделать их отдельными каталогами в одном проекте в решении.

Я просто хочу знать, нужно ли убеждать его использовать несколько проектов!

3

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

Я опираюсь на «Принципы OOD дяди Боба» в отношении управления пакетами. Они не очень хорошо известны (особенно по сравнению с его принципами SOLID для дизайна классов), но они разумны.

Взято из Принципов OOD дяди Боба

Первые три принципа упаковки касаются целостности упаковки, они подскажите что положить в пакеты:

• REP Эквивалент повторного использования релиза Принцип Гранула повторного использования – это гранула выпуска.
• КПК Общий принцип закрытия Классы, которые изменяются вместе, упаковываются вместе.
• CRP Общие классы принципов повторного использования, которые используются вместе упакованы вместе.

Последние три принципа касаются соединений между упаковками, и поговорим о метриках, которые оценивают структуру пакета система.

• ADP Принцип ациклических зависимостей Граф зависимостей пакеты не должны иметь циклов.
• SDP Стабильные зависимости Принцип Зависеть в направлении стабильности.
• SAP Конюшня Принцип абстракций Абстрактность возрастает с увеличением стабильности.

Это соответствует моему личному опыту, когда склонность к меньшему количеству проектов часто приводила к проблемам:

• Меньшее количество пакетов может привести к плохому управлению зависимостями. Отдельные проекты/сборки могут помочь предотвратить использование внутренних/частных классов и членов там, где они не должны быть

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

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

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

• Аналогично предыдущему, использование меньшего количества проектов приводит к постоянной перекомпиляции кода независимо от того, есть ли в нем соответствующие изменения. Однострочное изменение в очень большом проекте приведет к полной перекомпиляции.

Конечно, несколько проектов также могут иметь свои проблемы:

• Вы должны осознавать свои зависимости, чтобы избежать циклических ссылок (с которыми .NET справляется довольно хорошо, но Visual Studio помогает предотвратить)

• Ваши решения могут стать достаточно большими, чтобы оправдать подрешения, с которыми может быть сложно справиться

• Начальное время компиляции решения может быть медленнее

И, наконец, одна редко используемая функция в .NET заключается в том, что одна .DLL может содержать несколько модулей (фактически это несколько сборок, использующих один и тот же набор метаданных). Я бы не советовал использовать это, но интересно узнать, как это работает: http://www.codeproject.com/Articles/9364/Объединение NET-сборок с использованием ILMerge

1

На самом деле я согласен с вашим менеджером.

Несколько проектов означают несколько сборок, большое количество копий сборок и, как правило, более медленное время компиляции.

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

Некоторые веские причины для использования разных сборок:

• У вас есть архитектура плагина
• Сборки необходимо развернуть отдельно
• Вам нужно работать на нескольких языках
• Вы создаете библиотеки для использования в разных местах

4

Я нашел интересную статью о важности структуры (будь то проект или папка) в приложениях. Я скажу, что когда вы открываете решение и видите список проектов, их имена дают мне представление о том, как было построено приложение.

(пример шаблона проектирования MVP)

1. BLL (бизнес)
2. DAL (Постоянство (сопоставления, соглашения и т. д.))
3. Интернет
4. PL (уровень представления)
5. Test (Конечно, тесты должны быть в отдельном проекте)

Структура каталогов имеет основополагающее значение для вашего кода

«Как скажет вам любой дизайнер, это первые шаги в дизайне. процесс, который имеет наибольшее значение. Первые несколько штрихов, которые создают форму, нести в себе судьбу остальных.» — Кристофер Александр

(Кристофер Александер — архитектор. Не работал программист, он оказал влияние на многих людей, которые много думают о программирование. Его ранняя книга «Язык шаблонов» была оригинальной. вдохновение для движения Design Patterns. Он долго думал и тяжело о том, как строить красивые вещи, и эти размышления кажутся в значительной степени применимы и к созданию программного обеспечения.)

В радиоинтервью CBC Александр рассказал следующую историю. (перефразировано здесь): «Я работал с одним из моих студентов. очень трудно что-то построить. Он просто не знал как вообще поступить. Так что я сидел с ним, и я сказал это: Слушай, начните с выяснения того, что является самым важным. Получи прямо первый. Уясните это прямо себе в голову. Не торопись. Не быть слишком поспешным. Подумайте об этом некоторое время. Когда вы чувствуете, что у вас есть нашли его, когда у вас не осталось сомнений в том, что это действительно самое главное, тогда иди вперед и сделай это самым важным вещь. Когда вы сделали это самое важное, спросите себя, вы можете сделать его более красивым. Сократите чушь, просто поймите это прямо в вашей голове, если вы можете сделать это лучше или нет. Когда это будет сделано, и вы чувствуете, что не можете сделать его лучше, тогда найдите следующий самый главное»

Какие первые штрихи в приложении создают его общий форма? Это структура каталогов. Структура каталогов — это самое первое, с чем сталкивается программист при просмотре исходников код. Все вытекает из него. Все зависит от этого. Это несомненно, один из самых важных аспектов вашего исходного кода.

Рассмотрим разные реакции программиста при встрече различные структуры каталогов. Для стиля package-by-feature мысли прикладного программиста могут быть такими:

«Понятно. Здесь перечислены все основные функции приложения за один раз. Красиво.» «Посмотрим. Интересно, где этот предмет находится…. О, вот он является. И все остальное, что мне понадобится, тоже здесь, все в одно и то же место. Отлично.» Однако для послойного стиля мысли прикладного программиста могут быть примерно такими: «Эти каталоги ничего мне не говорят. Сколько функций в этом приложении? Бьет меня. Он выглядит точно так же, как и все остальные. Нет разницы совсем. Большой. Вот опять…» «Хм. Интересно, где этот предмет расположен …. Я думаю, его части разбросаны по всему приложению, разбросаны по все эти каталоги. Действительно ли у меня есть все, что мне нужно? Наверное мы узнаем позже.» «Интересно, это соглашение об именах все еще преследуется. Если нет, то мне придется искать его в другом директории.» «Вау, вы бы не могли взглянуть на размер каталог… хех.» Послойная упаковка в других доменах неэффективна

Источник

2

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

1

Из-за разделения ответственности. Это очень поможет неожиданным ссылкам между классами/объектами.

Для программистов WPF/Silverlight подумайте о шаблоне проектирования MVVM: разделение ViewModels и Views на два отдельных проекта гарантирует отсутствие ссылки объекта View на ViewModel.

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

Используйте разные проекты, если вам нужно

• Отдельные двоичные файлы для вашего решения, что обеспечивает гибкость при подготовке и развертывании исправлений/обновлений

• Возможность управления плагинами

• Использование, например, кодов C++ внутри вашего C#.

• Многоразовые компоненты. Типы, объявленные в сборках, можно повторно использовать в разных приложениях вашей компании для предоставления единого API.

Лучший способ работать с несколькими проектами/решениями в Visual Studio?

Задавать вопрос

спросил 12 лет, 7 месяцев назад

Изменено 9 лет, 7 месяцев назад

Просмотрено 23 тысячи раз

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

На данный момент это просто несколько форм и связанный с ними код.

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

Я рассмотрел возможность создания нового проекта в рамках одного из решений для библиотеки .dll/class, но счел это неправильным. (Пожалуйста, скажите, если я ошибаюсь).

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

Могу ли я затем включить это решение в другие, если мне нужно внести простое изменение и обновить его во всех проектах, или вместо этого я должен всегда работать над общим компонентом в отдельном экземпляре Visual Studio вне приложений, использующих его?

• visual-studio
• проекты-и-решения

Это правильный способ справиться с этой ситуацией.

Вы можете включить проекты в несколько решений, щелкнув решение правой кнопкой мыши и выбрав Добавить существующий проект…

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

3

1. Поместите общие коды в отдельное решение/проект как библиотеку классов,
2. В событии после сборки общих проектов скопируйте библиотеки DLL в определенный каталог,
3. Добавить общие dll из этого каталога в другие проекты/решения

Делая это каждый раз, когда вы создаете потребительские проекты, они будут автоматически использовать последние версии dll.

1

Вынос общего кода в отдельную общую сборку — отличный вариант.

Одна вещь, о которой следует подумать, — это хранить вашу общую бизнес-логику или код типа бизнес-объекта отдельно от кода, связанного с пользовательским интерфейсом, такого как настраиваемые элементы управления, — если вам нужно иметь две общие сборки.