This is the base project that houses all of the Content related items. Anything related to Views, TypeScript/JavaScript, and routing can be found in this project. When navigating for a particular script for a View, the script folders follow the same folder directory hierarchy as the Views. For example, if you were looking for the scripts related to ~/Student/Finder, they would be located in Scripts/Views/Student/
The Integration project is responsible for integrating the data retrieved from district databases into the Student Success Dashboard education databases.
This project also contains all of the Azure settings for the development environments. Any change that needs to be made can be made in the cscfg files. This project should be set as the default StartUp project to ensure that the Azure emulator is initiated upon start of debugging. Additionally all deployments to Azure are to be made through this project via right click -> publish.
The Application project contains the controller logic for the Student Success Dashboard. In addition to the controller logic, it also houses the logic for cleaning up Azure Blob storage. This cleanup routine runs out of an independent Azure Worker Role and serves to sweep out old temporary files lingering in Blob storage.
This project serves as the Business Logic Layer of the application. It does a lot of the heavy lifting, so to speak, for the application. You can find a business object by taking the name of the Controller and matching it to its corresponding Manager. For example, ProviderController will have most of its logic stored in the ProviderManager. Additionally, the file processing logic for the Student Success Dashboard is housed in the IO directory.
The Data project controls the Education data contexts for the Student Success Dashboard. The Education data context contains all DbSets associated with the different entities in the Domain project.
The Domain project houses all of the domain objects used by the Student Success Dashboard. These map directly to what Entity Frameworks generates in the database.
The Presentation project contains the ViewModel logic for the Student Success Dashboard. This project passes back ViewModels to the Business layer which it populates and returns to the views.
The Repositories project contains the means for the Student Success Dashboard to interact with the Education data contexts. These repositories follow the repository pattern and allow for adding, updating, removing and querying of items stored within the specific domain repository. It is also important to note that all Education repositories need to be “obtained” through the RepositoryContainer.
The Security project contains the logic for application security, Azure Access Control Service and the SendGrid mailer client. The logic for the SendGrid Mailer can be found Nested in Security/Net. It is important to note that under a free trial SendGrid only allows 200 emails a day so as the Student Success Dashboard project picks up steam a full version license will need to be procured.
The Common.Tests project is simply a type library for the testing projects.
The IntegrationTest project is designated for all integration tests that are desired to adequately test the Student Success Dashboard application. These tests check to make sure functions work across the system rather than focus on one piece of small functionality. They use a temporary database on localDB.
The UnitTest project is for all unit tests that are used for the Student Success Dashboard. As the development team adopted a TDD approach in designing the Student Success Dashboard, we wrapped functionality with appropriate unit tests. By utilizing TDD, the team not only reduced potential coding errors but also increased refactoring confidence by having a testing framework to fall back on to ensure that any potential refactoring still maintains the business logic integrity. Currently the UnitTest project is utilizing MS Test and Rhino Mocks.
With Visual Studio Ultimate edition you can use the SSD.Models project which has a System.layerdiagram file. This validates project references to satisfy the following architecture. This validation can run as part of the build process.
Return to the wiki Home