윈도우 앱개발을 향하여

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 마지막 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Last Responsible Moment

Make informed decisions

Deciding too early is a risk

Deciding too late is a risk

Defer decisions until LRM

Evolving the Architecture

Eliminate risk early

Technology may change

Markets may change

Preferences may change

Why Use Evolutionary Architecture?

Pros

Embraces unvertainty

Embraces change

Reduces risk

Cons

Assumes uncertainty

Assumes instability

Still has limitations

Where to Go Next

Books

Patterns of Enterprise Application Architecture

Clean Architecture

Domain-Driven Design

Dependency Injection in .NET

Pluralsite course

Domain-Driven Design Fundamentals

Domain-Driven Design in Practice

Modern Software Architecture

Microservices Architecture

Dependency Injection On-Ramp

Website

Martin Fowler: http://martinfowler.com

Greg Young: http://goodenoughsoftware.net

Udi Dahan: http://udidahan.com

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 마지막 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 일곱번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Outline

Test-Driven Development

Test Automation Pyramid

Pros and Cons

Test-Driven Development

Test-Driven Development is a software practice where we create a failing test first before we write any production code, and use this test to drive the design of the architecture.

1. Create a failing test for the simplest piece of functionality we need to create.

2. Get the test to pass (implement just enough production code to get that failing test to pass)

3. Improve the code (refactor our existing code)

4. Repeat 1~3 steps

TDD

Comprehensive suite of tests

Drives testable design

More maintainable

Eliminates fears to change

Types of Tests

What to test : Unit tests, Integration tests, Component tests, Service tests, UI tests

Why being tested : Functional tests, Acceptance tests, Smoke tests, Exploratory tests

How being tested : Automated tests, Semi-automated tests, Manual tests

Acceptance Tests

1. Eliminate user interface then replace to Acceptance Tests

2. Eliminate database then replace to in-memory Database

3. Eliminate dependencies in the infrastructure and cross-cutting concerns layer then replace to fake test doubles called mocks that act as surrogates for the real dependencies

Acceptance criteria should be written in the language of the business to describe business functionality that the application needs to provide.

Focus on the essential, and not implementation details

Minimize coded UI tests, Smoke test instead     

Minimize manual tests, Exploratory test instead

Why Create Testable Architecture?

Pros

Easier to test

Improves design

Eliminates fear to change code

Cons

Higher up-front cost

TDD requires discipline

Requires team buy-in

Demo

Uses NUnit, Moq, AutoMoq, SpecFlow

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 일곱번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 여섯번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Outline

Bounded Context

Microservices

Pros and Cons

Components

Components are how we would typically subdivide the layers of our architecture once it has grown beyond a manageable size. We typically implement components as separate projects within our overall solution, then when we build these projects we create output files like DLLs in C#, assemblies in .NET, jar files in Java, and gem files in Ruby. This allows us to work on the components individually, integrate them as necessary, and deploy them independently.

Our users interact with the application typically through a composite user interface, which calls the appropriate component stack, and presents the user interface as a unified view of the system. In addition, all of the data for each component stack are typically stored in a single database.

Single Domain Model

Creating a single unified domain model by merging all the functions that pointed to the same types of physical objects and mental concepts as a single entity can derive a problems as we try to model larger and larger domains. It becomes progressively harder to create a single unified domain model. The problem is that models are only applicable within a specific context(Sales and Support). When we try to force a model to work within multiple contexts, We have extra unused properties, methods, and validation rules that are applicable in one context, but not in other contexts.

A bounded context is the recognition of a specific contextual scope within which a specific model is valid. We constrain our domain model by each bounded context, and subdivide our models appropriately. Then we communicate state transitions of our cross boundary models from one domain to the other. We do this through clearly defined interfaces using either coordinated transactions or an eventual consistency model. This leads us to microservices.

Microservices

Microservice architectures subdivide monolithic applications; that is, the divide a single, large application into smaller subsystems. These microservices communicate with one another using clearly defined interfaces, typically over lightweight web protocols(like JSON over HTTP via res APIs).

Microservices can also subdivide large teams into smaller development teams; that is, one team for each microservice or set of microservices.

These services are also very independent of one another. Each one can have its own persistence medium, programming language, architecture, and OS. In addition, you can independently deploy each microservice and independently scale them as needed.

Microservices are similar in concept to SOA(Service oriented architecture).

Then...

How big should each microservice be?

Where should I draw the boundaries of each microservice?

Bounded context

Ideally, in most cases we want each domain, each microservice, each database, and each corresponding deevelopment team to line up to maximize Cohesion/coupling, Single domain of knowledge, Consistent data model, Independence. However there's still a lot of debate in the industry as to how small microservices should be and where to divide. even if each domain contains database, Information is still exchanged between bounded context via each bounded context set of microservices. There are definite pros and cons to both of these equally reasonable ways to organize your micorservices; however, it's up to each of you to decide what makes the most sense for your project and architect your microservices accordingly.

Why Use Microservices?

Pros

Flatter cost curve

High cohesion and low coupling

Independence : can use whatever technology, design pattern that most appropriate for each specific microservice

Cons

Higher up-front cost

Conway's' Law

Distributed system costs

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 여섯번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 다섯번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

The Screaming Architecture

"The architecture should scream the intent of the system!" - Uncle Bob

Organizing architecture around the use cases of the system. Use cases are representation of a user's interaction with the system.

We can organize our application's folder structure and namespaces according to the components that are used to build the software, components like models, views, and controllers or we can organize our folder structure and namespaces according to the use cases of the system, concepts that pertain to user's interactions with objects in the system like customers, products and vendors. 

Why Use Functional Organization?

Pros

Spatial locality : items that are used together live together

Easy to navigate the folder structure

Avoid vendor lock-in

Cons

Lose framework conventions : so we typically have to tell framework where things are located

Lose automatic scaffolding

Categorical is easier at first

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 다섯번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 네번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Outline

Commands and Queries

CQRS Architectures

Pros and Cons

Command-Query Separation

Command

Does something

Should modify state

Should not return a value

Query

Answers a question

Should not modify state

Should return a value

Command-Query separation is a good idea, but not always possible.

e.g. Pop a stack (Remove item - command, Return top item - query)

e.g. Create a new record (Create record - command, Return new ID - query)

So in general we should strive to maintain command query separation where possible.

Command Query Responsibility Separation(CQRS) Architecture

Expand command query separation to the architectural level.

Dividing the architecture into a command stack, and a query stack, starting at the application layer. Because queries should be optimized for reading data, whereas commands should be optimized for writing data. 

Command execute behaviors in the domain model, mutate state, raise event, and write to the database.

Queries use whatever means is most suitable to retrieve data from the database, project it into a format for presentation, and display it to the user.

This change increases both the performance of the commands and queries, but equally important, it increases the clarity of the respective code. CQRS is domain-centric architecture done in a smart way

Three types of CQRS Architecture

Single-database CQRS : Commands use domain, Queries use database (Simplest)

Two-database CQRS : Read and writhe databases, Commands use write DB, Queries use read DB, Eventual consistency between databases, Orders of magnitude faster

Event Sourcing CQRS : do not store the current state of our entities in a normalized data store. Store events (store historical record of all events in a persistence medium called an event store. Replay events. Modify entity. Store new event. Update read database.

Complete audit trail, Point-in-time reconstruction, Replay events(good for debugging and testing), Multiple read database, Rebuild production database.

Why Use CQRS?

Pros

More efficient design

Optimized performance

Event sourcing benefits

Cons

Inconsistent across stacks

More complex

Event sourcing costs

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 네번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 세번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Outline

Application Layer

Dependency Inversion Principle

Pros and Cons

What are Layers?

Layers are boundaries or vertical partitions of an application designed to represent different levels of abstraction, maintain the single responsibility principle, isolate developer roles and skills, help support multiple implementations, and assist with varying rates of change.

Essentially, layers are the way that we slice an application into manageable units of complexity.

Classic Three-layer Architecture

User interface Layer : provides the user with an interface into the application 

Business Logic Layer : contains the business logic of the application

Data Access Layer : contains the logic to read and write to the database.

Modern Four-layer Architecture

Presentation Layer : provides the user with an interface into the application

Application Layer : embeds the use cases of the application as executable code and abstractions

Domain Layer : contains only the domain logic of the application

Infrastructure Layer : oftentimes it makes sense to divide this layer into one or more projects

e.g. common variation is to create a separate project for persistence, and a separate project for the remaining infrastructure. In diagram on the left create Persistence project to provides the application with an interface to the database or other persistent storage.

Cross-cutting Concerns Layer : aspects of the application that cross all the layers of the system

Application Layer

Implements use cases as executable code

e.g. a customer searches for a project, adds it to their cart, and pays with a credit card.

High-level representations of application logic.

e.g. a query that searches for our project for our customer or a command that adds a product to their shopping cart.

The application layer knows about the domain layer, that is, it has a dependency on the domain, but it does not know about the presentation, persistence or infrastructure layers(no dependencies on the outer layers of the application).

The application layer, however, does contain interfaces for its dependencies that these respective outer layers then implement. Then we use an IoC framework(inversion of Control framework) and dependency injection to wire up all the interfaces and their implementations at run time.

We can follow the flow of control through the application from the users at the top of the diagram down to the database and OS at the bottom of the diagram. In addition, we can follow the dependency arrows, which flow both upwards and downwards towards the domain.

Unlike classic three layer architecture, Persistence and Infrastructure layer depends on application layer. These inverted dependencies comes from the dependency inversion principle. It states that abstraction should not depend on details, rather, details should depend on abstractions. So in the persistence and infrastructure layers we implement the inversion of control pattern. That is, our dependencies oppose the flow of control in our application. This provides several benefits, such as providing independent deployability. That is, we can replace an implementation in production without affecting the abstraction that is depends upon. It also makes architecture more flexible and maintainable as well. For example, we can swap out our persistence medium and infrastructure dependencies without having negative side effects ripple throughout both the application and domain layers. This is highly useful for agile applications where we often defer implementation decisions as late as possible when we have a much better understanding of the specific needs of our application and its implementations. This it a strategy referred to in Agile software development as the last responsible moment.

Sometimes we need to add an additional dependency from the persistence project directly to the domain project when using an Object Relational Mapper(ORM). This is necessary for the ORM to map domain entities to tables in the database since the persistence layer needs to know about the entities contained int the domain layer. Using an ORM is optional when creating clean architecture, but it can save a tremendous amount of development time if used correctly.

Demo

In the Presentation project : SalesController that has a dependency on the ICreateSalesCommand interface in the application project.

In the Application project : CreateSaleCommand class implements ICreateSalesCommand interface and contains the high level application logic that fulfills the use case for creating a new sale. The class has a dependency on the IDatabaseService interface and IInventoryService interface both of which contained in the application project as well.

In the Persistence project :  DatabaseService class implements the IDatabaseService interface

In the Infrastructure project : InventoryService class implements the IInventoryService interface.

All of the dependencies point towards the application and thus transitively towards the domain. All of the details, that is implementations, depend upon abstractions, which are interfaces, and we utilize inversion of control for both the persistence and Infrastructure projects dependency on the application project.

Cross-cutting concerns are a bit different, as there are typically multiple projects that all have dependencies upon them. So Cross-cutting concerns project store both the interfaces and the implementations(IDateService interface and DateService class). Then multiple classes(CreateSaleCommand, SalesController, DatabaseService, Sale and InventoryService uses IDateService)

Why Use an Application Layer

Pros

Focus on use cases

Easy to understand

Follows DIP(Dependency Inversion Principle

Cons

Additional layer cost : Layers in software architecture are expensive to create and maintain

Requires extra thoughts : to separate application layer from domain layer

IoC is counter-intuitive

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 세번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 두번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Outline

Domain-centric Architecture

Types of Domain-centric Architectures

Pros and Cons

Database-centric vs Domain-centric Architecture

On classic three-layer Database-centric Architecture, Data Access is essential(center of architecture). then Business Logic, then UI

On Domain-centric Architecture let Domain in the center and making the database just an implementation detail outside of the architecture.

"설계의 최우선 관심사는 집의 사용가능성(domain)을 보장하는 것이지, 그 집이 벽돌(data access)로 지어질것을 보장하는 것이 아니다."

=> 집의 공간과 사용성은 필수적인 고려대상이나 건물의 재질과 외관장식은 디테일에 불과하다.

Types of Domain-centric Architectures

1. Hexagonal Architecture, Alistair Cockburn

2. Onion Architecture, Jeffrey Palermo

3. Clean Architecture, Uncle Bob

Put the domain model at the center, wrap it in an application layer, which embeds the use cases, adapts the application to the implementation details, and all dependencies should point inwards towards the domain

Pros and Cons

Pros

Focus on domain(which is essential to the inhabitants of the architecture)

Less coupling between the domain logic and the implementation details

Allows for DDD(Domain Driven Design, set of strategies for handling business domains with a high degree of complexity)

Cons

Requires more thought

Initial higher cost

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 두번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 첫번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Outline

Levels of Architectural Abstraction

What is Bad Architecture?

What is Good Architecture?

What is Clean Architecture?

Levels of Architectural Abstraction

System : the most abstract representation of software

Sub-system : System can be represented as a set of one or more subsystems

Layers : Sub-systems are typically divided into one or more layers

Components : Layers are often subdivided into one or more components

Classes : Components contain classes

Data and Methods : Classes contains data and methods

What is Bad Architecture?

Complex

Incoherent : the parts don't seem like they fit together

Rigid : hard to change or evolve the architecture

Brittle : touching a part of the code over here might break another part of the code somewhere else

Untestable

==> Unmaintainable

What is Good Architecture?

Simple

Understandable

Flexible

Emergent

Testable

==> Maintainable

What is Clean Architecture?

Architecture that is designed for the inhabitants(User, developers who building or maintaining the system) of the architecture. Not for the architect or the machine. Clean architecture is a philosophy of architectural essentialism. It's about focusing on what is truly essential to the software's architecture versus what is just an implementation detail.

Focus on the essential

Build only what is necessary

Optimize for maintainability

Context is king

All decisions are a tradeoff

Align with business goals

Use your best judgement

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 첫번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.

Copyright

이 모든 내용은 Pluralsight에 Mike Halsey가 올린 'Windows File System Troubleshooting'라는 강의의 첫번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/windows-file-system-troubleshooting/description). 강의 원작자분께 게시허가도 받았습니다.

Content

1. The Windows File System in depth

2. Troubleshooting Disk and File Errors

3. Managing Permissions, Ownership, and Auditing

4. Managing Security and Security Permissions

Outline

The Windows File and Folder Structure

Windows System Files and Folders

Critical Windows System Files and Folders

Software and App Folders

The Windows File and Folder Structure

PC Firmware Systems

BIOS (7, 8.1, 10)

Uses a single boot partition

System Reserved resides at the beginning of drive 0 on the PC

The System Reserved partition contains all of Windows boot and recovery tools

UEFI (Unified Extensible Firmware Interface) (8.1, 10)

Uses a triple boot partition structure located on drive 0

These include a 100MB EFI partition, a 300MB Recovery partition, and a hidden Security partition

32-bit Windows installations, may only see a System Reserved partition due to lack of support on some 32-bit chipsets

Folders in root folder (e.g., C: drive)

Perflogs folder

Contains Data Collector Sets and log files created by Performance Information and Tools, and Performance Monitor

Program Files and Program Files (x86) folder

win32 applications (not store apps) are installed. 64-bit Windows installations maintain an (x86) folder for compatibility purposes, to separate these from 64-bit applications

Users folder

Contains all files related directly to the currently signed-in user

Windows folder

The repository of core OS files, drivers, run-time files, and other essential files

Inside the root folder of the Windows installation drive are hidden files and folders

System Volume Information folder

Can be found on all drives protected by System Restore

Other hidden files relate to startup or virtual memory, they are bootmgr, BOOTNXT, hiberfil.sys, pagefile.sys, and swapfile.sys. These are all related to startup or things like virtual memory

Windows System Files and Folders

C:Windows

Boot folder

Contains files necessary for the OS to start

Debug folder

Contains error logs

Fonts folder

Contains the installed fonts and typefaces (can't just copy fonts into it)

Globalization folder

Contains language packs, dictionary files, and files related to location

Media folder

Contains audio and video associated with the OS

Prefetch folder

A store for commonly used files. Windows tries to anticipate what you need to load and makes a copy here to load them more quickly.

Resources folder

Contains ease-of-access and other themes

Web folder

Contains images for the Windows 8.1 and 10 lock screen, and desktop wallpapers

MSOCache folder

Only appear on PCs with Microsoft Office installed, it contains a backup copy of the Office installer

Logs folder

Contains log files for many Windows components

etc...

Deskop.ini

A hidden file found in each folder that contains customization and other options for how the folder should be displayed in File Expolorer

Minidump

Contains crash reports created by applications on the PC, they have the file extension .dmp

%LOCALAPPADATA%\CreashDumps

Contains user-specific crash dump files

MEMORY.DMP

Files are Blue Screen of Death (BSOD) crash files, they are found either in the root of the Windows install drive, or in the Windows\System32 folder

# .dmp files cannot be read by Windows Notepad, but can be opened using Visaul Studio, the Windows Driver Kit(WDK), Windows Software Development Kit(SDK). BSOD MEMORY.DMP files can be opened by third-party apps such as BlueScreenView

C:User\specificUserName

AppData folder

The User folder contains application, configuration and driver setting unique to the currently signed-in user

Roaming folder

Contains data and setting that can move with your user account such as Domain files and settings

Local folder

Contains user settings that are tied to the PC

LocalLow folder

is for local settings with low-level access such as web browser privacy or protected mode files

Critical Windows System Files and Folders

C:Windows

SoftwareDistribution folder

Contains all files relating to Windows Update. Should Windows Update malfunction, the contents of this folder can be deleted to reset Windows Update. If there is problem with Windows Update, it's perfectly okay to delete the contents of this folder to reset Windows Update. Just delete them after restart.

System32 folder

Contains all the core files that make up the Windows operating system

Configuration folder

Contains Registry files for the Windows installation. Additional user-specific Registry files can be found in the %userprofile%\ntuser.dat and %userprofile%\AppData\Local\Microsoft\Windows folders

SysWoW64 and WinSxS

Contain (side-by-side) copies of Dynamic Link Library(DLL) and other files for app and driver compatibility both between 32-bit and 64-bit software, also where different apps and drivers may call and require different versions of the same file.

C:ProgramData

Contains application and configuration data for installed applications that pertains to all users on the PC

Software and App Folders

Program Files folder

All win32 desktop applications are installed in 32-bit versions of Windows, and where 64-bit applications are installed for 64-bit versions of Windows

WindowsApps folder

Install location for Windows Store apps in Windows 8.1 and 10. It is protected by heavy security and is inaccessible to even Administrator on the PC

Program FIles (x84) folder

Only be seen in 64-bit Windows installations. All 32-bit win 32 applications are installed 

Summary (생략)

출처

이 모든 내용은 Pluralsight에 Mike Halsey가 올린 'Windows File System Troubleshooting'라는 강의의 첫번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/windows-file-system-troubleshooting/description). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.

Copyright

이 글은 Channer9에 Andy Wigley, BobTabor, Clint Ruthas, Chavin이라는 4명의 저자가 만드신 'Windows 10 development for absolute beginners'라는 무료강의 시리즈의 정리노트(UWP Cheat Sheet.txt)로 누구나 다운받을 수 있는 파일의 내용을 욺긴 것입니다. 

UWP Cheat Sheet

***************

UWP-004 - What is XAML?

=======================================

XAML - XML Syntax, create instances of Classes that define the UI.

UWP-005 - Understanding Type Converters

=======================================

Type Converters - Convert literal strings in XAML into enumerations, instances of classes, etc.

UWP-006 - Understanding Default Properties, Complex Properties and the Property Element Syntax

=======================================

Default Property ... Ex. sets Content property:

<Button>Click Me</Button>

Complex Properties - Break out a property into its own element syntax:

        <Button Name="ClickMeButton"

                HorizontalAlignment="Left"

                Content="Click Me"

                Margin="20,20,0,0" 

                VerticalAlignment="Top" 

                Click="ClickMeButton_Click"

                Width="200"

                Height="100"

                >

            <Button.Background>

                <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">

                    <GradientStop Color="Black" Offset="0"/>

                    <GradientStop Color="Red" Offset="1"/>

                </LinearGradientBrush>

            </Button.Background>

        </Button>

UWP-007 - Understanding XAML Schemas and Namespace Declarations

=======================================

Don't touch the schema stuff - it's necessary!

Schemas define rules for XAML, for UWP, for designer support, etc.

Namespaces tell XAML parser where to find the definition / rules for a given element in the XAML.

UWP-008 - XAML Layout with Grids

========================================

Layout controls don't have a content property ...

they have a Chidren property of type UIElementCollection.

By embedding any control inside of a layout control, you are implicitly calling the Add method of the Children collection property.

<Grid Background="Black">

  <Grid.RowDefinitions>

    <RowDefinition Height="*" />

    <RowDefinition Height="*" />

    <RowDefinition Height="*" />

  </Grid.RowDefinitions>

  <Grid.ColumnDefinitions>

    <ColumnDefinition Width="*" />

    <ColumnDefinition Width="*" />

    <ColumnDefinition Width="*" />

  </Grid.ColumnDefinitions>

</Grid>

Sizes expressed in terms of:    Explicit pixels - 100

Auto - use the largest value of elements it contains to define the width / height

* (Star Sizing) - Utilize all the available space

1* - Of all available space, give me 1 "share"

2* - Of all available space, give me 2 "shares" 

3* - Of all available space, give me 3 "shares"

6 total shares ... 3* would be 50% of the available width / height.

Elements put themselves into rows and columns using attached property syntax:

...

  ...

  <Button Grid.Row="0" />

</Grid>

- When referencing Rows and Columns ... 0-based.

- There's always one default implicit cell: Row 0, Column 0

- If not specified, element will be in the default cell

UWP-009 - XAML Layout with StackPanel

====================================

<StackPanel>

  <TextBlock>Top</TextBlock>

  <TextBlock>Bottom</TextBlock>

</StackPanel>

- Vertical Orientation by default.

- Left-to-right flow by default when Horizontal orientation.

- Most layouts will combine multiple layout controls.

- Grid will overlap controls.  StackPanel will stack them.

UWP-017 - XAML Layout with the RelativePanel

====================================

It basically defines an area within which you can position and align child objects 

-- in relation to each other 

-- or in relation to the parent panel.

Controls use attached properties to position themselves.

Panel alignment relationships (AlignTopWithPanel, AlignLeftWithPanel, ? are applied first.

Sibling alignment relationships (AlignTopWith, AlignLeftWith, ? are applied second.

Sibling positional relationships (Above, Below, RightOf, LeftOf) are applied last.

<RelativePanel MinHeight="300" Grid.Row="1">    

    <Rectangle Name="RedRectangle" RelativePanel.AlignRightWithPanel="True" />

    <Rectangle RelativePanel.LeftOf="RedRectangle" />

</RelativePanel>

UWP-018 - XAML Layout with the SplitPanel

====================================

The split view allows us to create a panel that can be displayed or hidden.  

We would use the SplitView to implement hamburger navigation.

The are two parts to a SplitView:

1) The part that is hidden by default (Pane)

2) The part that is shown by default (Content)

You define other controls inside of the SplitView.Pane and SplitView.Content.

<SplitView Name="MySplitView" 

    CompactPaneLength="50" 

    IsPaneOpen="False" 

    DisplayMode="CompactInline" 

    OpenPaneLength="200" >

    <SplitView.Pane>

    </SplitView.Pane>

    <SplitView.Content>

    </SplitView.Content>

</SplitView>

Inline ?Panel completely covers content.  When expanded, panel pushes content.

CompactInline ?Pane covers most of the Content.  When expanded, panel pushes content.

Overlay ?Panel completely covers content.  When expanded, panel covers content.

CompactOverlay ?Panel covers most of the content.  When expanded, panel covers content.

Open / Close Pane in C#: MySplitView.IsPaneOpen = !MySplitView.IsPaneOpen;

UWP_019 - Working with Navigation

====================================

App > Window > Frame > MainPage

You can load pages into a child frame or into the root frame:

Frame.Navigate(typeof(Page2), additionalParameter);

You can retrieve additionalParameter on the page you navigated to:

    protected override void OnNavigatedTo(NavigationEventArgs e)

    {

      value = (string)e.Parameter;

    }

Traverse back stack (history):

if (Frame.CanGoBack) {

  Frame.GoBack();

}

if (Frame.CanGoForward) {

  Frame.GoForward();

}

Create a global variable by declaring a static internal field in the App class definition.

UWP-020 - Common XAML Controls - Part 1

====================================

<CheckBox Name="MyCheckBox" Content="Agree?" Tapped="MyCheckBox_Tapped" />

CheckBoxResultTextBlock.Text = MyCheckBox.IsChecked.ToString();

<RadioButton Name="YesRadioButton" Content="Yes" GroupName="MyGroup" checked="RadioButton_Checked" />

<RadioButton Name="NoRadioButton" Content="No" GroupName="MyGroup" Checked="RadioButton_Checked" />

RadioButtonTextBlock.Text = (bool)YesRadioButton.IsChecked ? "Yes" : "No";

<ComboBox SelectionChanged="ComboBox_SelectionChanged" >

    <ComboBoxItem Content="Fourth" />

    <ComboBoxItem Content="Fifth" />

    <ComboBoxItem Content="Sixth" IsSelected="True" />

</ComboBox>

if (ComboBoxResultTextBlock == null) return;

var combo = (ComboBox)sender;

var item = (ComboBoxItem)combo.SelectedItem;

ComboBoxResultTextBlock.Text = item.Content.ToString();

<ListBox Name="MyListBox" SelectionMode="Multiple" SelectionChanged="ListBox_SelectionChanged">

    <ListBoxItem Content="First" />

    <ListBoxItem Content="Second" />

    <ListBoxItem Content="Third" />

</ListBox>

var selectedItems = MyListBox.Items.Cast<ListBoxItem>()

                      .Where(p => p.IsSelected)

                        .Select(t => t.Content.ToString())

                          .ToArray();

ListBoxResultTextBlock.Text = string.Join(", ", selectedItems);

<Image Source="Assets/logo.png" Stretch="UniformToFill" />

<ToggleButton Name="MyToggleButton" Content="Premium Option" IsThreeState="True" Click="MyToggleButton_Click" />

ToggleButtonResultTextBlock.Text = MyToggleButton.IsChecked.ToString();

<ToggleSwitch>

    <ToggleSwitch.OffContent>

        <TextBlock Text="I'm off right now." />

    </ToggleSwitch.OffContent>

    <ToggleSwitch.OnContent>

        <TextBlock Text="I'm on!" />

    </ToggleSwitch.OnContent>

</ToggleSwitch>

UWP-021 - Implementing a Simple Hamburger Navigation Menu

====================================

Jerry Nixon's Example: http://bit.do/hamburger-nav

Use Character Map to find the code to display icons using Segoe MDL5 Assets.

Hamburger:  &#xE700;

Use ListBox and ListBoxItems for the navigation links inside of a SplitView.

UWP-025 - Common XAML Controls - Part 2

====================================

<TimePicker ClockIdentifier="12HourClock" />

<CalendarDatePicker PlaceholderText="choose a date" />

<CalendarView SelectionMode="Multiple"

SelectedDatesChanged="MyCalendarView_SelectedDatesChanged" />

private void MyCalendarView_SelectedDatesChanged(CalendarView sender, CalendarViewSelectedDatesChangedEventArgs args)

{

    var selectedDates = sender.SelectedDates.Select(p => p.Date.Month.ToString() + "/" + p.Date.Day.ToString()).ToArray();

    var values = string.Join(", ", selectedDates);

    CalendarViewResultTextBlock.Text = values;

}

<Button Content="Flyout">

  <Button.Flyout>

    <Flyout x:Name="MyFlyout">

    </Flyout>

  </Button.Flyout>

</Button>

MyFlyout.Hide();

<Button Content="FlyoutMenu">

  <Button.Flyout>

    <MenuFlyout Placement="Bottom">

      <MenuFlyoutItem Text="Item 1" />

      <MenuFlyoutItem Text="Item 2" />

      <MenuFlyoutSeparator />

      <MenuFlyoutSubItem Text="Item 3">

        <MenuFlyoutItem Text="Item 4" />

        <MenuFlyoutSubItem Text="Item 5">

          <MenuFlyoutItem Text="Item 6" />

          <MenuFlyoutItem Text="Item 7" />

        </MenuFlyoutSubItem>

      </MenuFlyoutSubItem>

      <MenuFlyoutSeparator />

      <ToggleMenuFlyoutItem Text="Item 8" />

    </MenuFlyout>

  </Button.Flyout>

</Button>

<!-- You can apply this to anything ... ex. Image: -->

<!-- https://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn308516.aspx -->

<AutoSuggestBox Name="MyAutoSuggestBox" 

    QueryIcon="Find" 

    PlaceholderText="Search" 

    TextChanged="MyAutoSuggestBox_TextChanged"  />

private string[] selectionItems = new string[] { "Ferdinand", "Frank", "Frida", "Nigel", "Tag", "Tanya", "Tanner", "Todd" };

private void MyAutoSuggestBox_TextChanged(AutoSuggestBox sender, AutoSuggestBoxTextChangedEventArgs args)

{

    var autoSuggestBox = (AutoSuggestBox)sender;

    var filtered = selectionItems.Where(p => p.StartsWith(autoSuggestBox.Text)).ToArray();

    autoSuggestBox.ItemsSource = filtered;

}

<Slider Maximum="100" Minimum="0" />

<ProgressBar Maximum="100" Value="{x:Bind MySlider.Value, Mode=OneWay}" />

<ProgressRing IsActive="True" />

UWP-026 - Working with the ScrollViewer

====================================

<ScrollViewer 

HorizontalScrollBarVisibility="Auto" 

        VerticalScrollBarVisibility="Auto">

</ScrollViewer>

You can put anything inside of it, however, don't put it inside of a StackPanel!

UWP-027 - Canvas and Shapes

====================================

Canvas allows you to do absolute positioning via attached properties.

<Line X1="10" 

X2="200" 

Y1="10" 

Y2="10" 

Stroke="Black" 

Fill="Black" 

StrokeThickness="5" 

StrokeEndLineCap="Triangle" />

<Polyline Canvas.Left="150" 

Canvas.Top="0" 

        Stroke="Black" 

        StrokeThickness="5" 

        Fill="Red"

        Points="50,25 0,100 100,100 50,25" 

StrokeLineJoin="Round" 

StrokeStartLineCap="Round" 

StrokeEndLineCap="Round" />

<Rectangle />

<Ellipse />

Canvas.ZIndex="100"

The higher the ZIndex, the higher in the stack it appears (covering what is below it).

UWP-028 - XAML Styles

====================================

https://dev.windows.com/en-us/design

<Page.Resources>

    <SolidColorBrush x:Key="MyBrush" Color="Brown" />

    <Style TargetType="Button" x:Key="MyButtonStyle">

        <Setter Property="Background" Value="Blue" />

        <Setter Property="FontFamily" Value="Arial Black" />

        <Setter Property="FontSize" Value="36" />

    </Style>

</Page.Resources>

Binding: {StaticResource ResourceName}

<Button Content="OK" Style="{StaticResource MyButtonStyle}" />

Create Page or Application level resource dictionaries

<Application.Resources>

</Application.Resources>

Split up your styles into Resource Dictionary files:

<!-- Dictionary1.xaml -->

<ResourceDictionary>

    <SolidColorBrush x:Key="brush" Color="Red"/>

</ResourceDictionary>

<Page>

    <Page.Resources>

        <ResourceDictionary>

            <ResourceDictionary.MergedDictionaries>

                <ResourceDictionary Source="Dictionary1.xaml"/>

                <ResourceDictionary Source="Dictionary2.xaml"/>

            </ResourceDictionary.MergedDictionaries>

        </ResourceDictionary>

    </Page.Resources>

    <TextBlock Foreground="{StaticResource SomeStyle}" Text="Hi" />

</Page>

UWP-029 - XAML Themes

====================================

http://bit.do/theme-resources

Put your mouse on a style, hit F12 to open generic.xaml

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">

    <Rectangle Width="100" Height="100" Fill="{ThemeResource SystemAccentColor}" />

    <Rectangle Width="50" Height="50" Fill="{ThemeResource SystemColorWindowColor}" />

</Grid>

<App RequestedTheme="Light">

High Contrast themes override styles.

Lots of different styles of system styles defined:

<TextBlock Text="page name" Style="{StaticResource HeaderTextBlockStyle}" />

Many styles defined in generic.xaml used BasedOn attribute ... and you can too!

UWP-037 - Utilizing the VisualStateManager to Create Adaptive Triggers

=================================================

VisualStateManager manages changes to XAML element attributes based on screen size using Adaptive Triggers (MinWindowWidth, MinWindowHeight) and Setters (to change target property values).

<VisualStateManager.VisualStateGroups>

  <VisualStateGroup>

    <VisualState x:Name="NarrowLayout">

      <VisualState.StateTriggers>

        <AdaptiveTrigger MinWindowWidth="0"/>

      </VisualState.StateTriggers>

      <VisualState.Setters>

        <Setter Target="MyImage.Width" Value="200" />

        <Setter Target="LayoutGrid.Background" Value="Blue" />

      </VisualState.Setters>

    </VisualState>

    <VisualState x:Name="WideLayout">

      <VisualState.StateTriggers>

        <AdaptiveTrigger MinWindowWidth="600"/>

      </VisualState.StateTriggers>

      <VisualState.Setters>

        <Setter Target="MyImage.Width" Value="200" />

        <Setter Target="LayoutGrid.Background" Value="Blue" />

      </VisualState.Setters>

    </VisualState>

  </VisualStateGroup>

</VisualStateManager.VisualStateGroups>

UWP-038 - Working with Adaptive Layout

=======================================

http://bit.do/adaptive-ui

Use adaptive triggers to move StackPanels (filled with content) into different Grid cells.

UWP-039 - Adaptive Layout with Device Specific Views

======================================================

Choose different versions of files to use based on the device running the app.

Example:

/DeviceFamily-Mobile

-- MainPage.xaml

/DeviceFamily-Desktop

-- MainPage.xaml

... or use a different file suffix for different device specific views:

MainPage.DeviceFamily-Mobile.xaml

MainPage.DeviceFamily-Desktop.xaml

http://bit.do/device-specific-views

UWP-40 - Data Binding to the GridView and ListView Controls

==========================================================

Bind to a List<T> where T is a POCO in your app (I put mine in the Models folder).

<Page

  ...

  xmlns:data="using:xBindDataExample.Models">

  <Page.Resources>

    <DataTemplate x:DataType="data:Book" x:Key="BookDataTemplate">

      <StackPanel HorizontalAlignment="Center">

        <Image Source="{x:Bind CoverImage}" />

        <TextBlock Text="{x:Bind Title}" />

        <TextBlock Text="{x:Bind Author}" />

      </StackPanel>

    </DataTemplate>

  </Page.Resources>

  ...

  <GridView ItemsSource="{x:Bind Books}" 

    IsItemClickEnabled="True" 

    ItemClick="GridView_ItemClick"

    ItemTemplate="{StaticResource BookDataTemplate}">

  </GridView>

  ...

Code Behind

------------

public sealed partial class MainPage : Page

{

  private List<Book> Books;

  public MainPage()

  {

    this.InitializeComponent();

    Books = BookManager.GetBooks();

  }

  private void GridView_ItemClick(object sender, ItemClickEventArgs e)

  {

    var book = (Book)e.ClickedItem;

    ResultTextBlock.Text = "You selected " + book.Title;

  }

}

UWP-041 - Keeping Data Controls Updated with ObservableCollection

=======================================

If the contents of List<T> will change, make sure you use ObservableCollection<T> instead!

UWP-042 - Utilizing User Controls as Data Templates

========================================

If you intend to combine the VisualStateManager with data bound controls, you will need to put your Data Template code inside of a User Control, then create the VisualStateManager code inside of the User Control.

1) Create a User Control.

2) Cut the Data Template out of the MainPage.xaml and copy it into the User Control.

3) Reference the User Control from inside the Data Template:

<local:ContactTemplate HorizontalAlignment="Stretch" VerticalAlignment="Stretch" />

4) Modify the contents of the User Control changing x:Bind statements to utilize object.property notation:

<UserControl>

  <StackPanel>

    <Image Source="{x:Bind Contact.AvatarPath}" />

    <TextBlock Text="{x:Bind Contact.FirstName}" />

    <TextBlock Text="{x:Bind Contact.LastName}" />

  </StackPanel>

</UserControl>

5) Add this in the User Control's Code Behind:

public Models.Contact Contact { get { return this.DataContext as Models.Contact; } }

public ContactTemplate()

{

  this.InitializeComponent();

  this.DataContextChanged += (s, e) => Bindings.Update();

}

출처

이 글은 Channer9에 Andy Wigley, BobTabor, Clint Ruthas, Chavin이라는 4명의 저자가 만드신 'Windows 10 development for absolute beginners'라는 무료강의 시리즈에서 강의 정리노트(UWP Cheat Sheet.txt)로 누구나 다운받을 수 있는 파일의 내용을 욺긴 것입니다. 강의는 더 많은 내용과 Demo를 포함하고 있습니다.