Skip to content

Home

Jump to bottom
John Bales edited this page Nov 8, 2016 · 7 revisions

Application Architecture Framework

Solution Projects

  1. Core – The Core project represents the cross-cutting location where you would place the following list of items. What this means is that you would reference the Core project in virtually every other project in the solution.

    1. Contracts – These are the interfaces that would be used for the Dependency Injection mappings.
    2. Enums – The central location for all enumeration that the application would use.
    3. Helpers – This represents a central location where helpers would be places. Each project in the solution may have the need for a sharable help class, this would be the place to put that.
    4. ViewModels – These are the object that would be used as view models for the MVC views and also the data transformation object (DTOs) that each layer would be able to pass along to the next.

  2. Data – The Data project is where the repository classes belong. This is also where the Entity Framework .edmx model would be created. When a repository class requests data from the model, the entity would be immediately transformed into a ViewModel and then returned so that the domain can take it, perform any business logic and then pass it along to the UI.

  3. Domain – The Domain project is where all business logic would be placed. Beyond that, this is where aggregate roots would be references to gain access to “Child” information.

  4. Infrastructure – This Infrastructure project is where the dependency inject container modules are placed. This is also where you might place things like Automapper, Logging, and the like. The idea is that these things are configurable things that the entire application would potentially use.

    1. IoC Modules – IoC modules are DI container for specific areas of the architecture.
    2. Data – Data only interface to class mappings
    3. Domain – Domain only interface to class mappings

  5. Services – This project represents the REST services that clients could use to access the core domain logic in the application and data behind the applications logic.

    1. Controllers – For each aggregate root in the domain you would potentially have a controller that represents the clients’ ability to work with that domain.

  6. UI – This project represents the MVC client application that the user would interact with. This is where the look & feel and usability would be.

    1. Controllers – For each aggregate root in the domain you would potentially have a controller that would communicate to the service layer where an end-point would exists for that domain root.

    2. Helpers – This is where you would place any helper that is shared in the UI project. For example you would place the service proxy class here which is an abstraction to getting access to the service controllers.

    3. Scripts – For each view/partial/page in the UI you may need a JavaScript module to handle client/browser specific functionalities. This is where you would place that code. Currently the architecture is set up to support the jQuery Widget Factory.

  7. Tests – This is where you would place all of the Unit Tests the application would need to execute to ensure it is in a healthy state.

Visual Studio Publish Profiles

The following information describes how to create deployment profiles inside of Visual Studio so that you can publish the application and services to your local IIS to host and run locally. The reason for this is so that as a developer you know that when the application is deployed to a server it will operate as intended. Furthermore, so the relationship between the application and services as such that they communication properly. The profile names and deployment location can be whatever you desire.

Application Deployments

  1. Right click on the UI project
  2. Select Publish…
  3. With Profile selected on the left, select Custom under Select a publish target
  4. Enter a name for the Profile and click Ok. Example: Application
  5. With Connection selected on the left, select File System in the Publish Method drop down list
  6. Set the Target Location for where the compiled files will be deployed and click next. Example: C:\Projects\Deployments\Application
  7. With Settings selected on the left, select Debug in the Configuration drop down list
  8. Expand the File Publish Options section and check the following boxes and click next:
    1. Delete all existing files prior to publish
    2. Precompile during publishing
  9. With Preview selected on the left, you are now ready to publish the web application. Click Publish

Services Deployments

  1. Right click on the Services project
  2. Select Publish…
  3. With Profile selected on the left, select Custom under Select a publish target
  4. Enter a name for the Profile and click Ok. Example: Services
  5. With Connection selected on the left, select File System in the Publish Method drop down list
  6. Set the Target Location for where the compiled files will be deployed and click next. Example: C:\Projects\Deployments\Services
  7. With Settings selected on the left, select Debug in the Configuration drop down list
  8. Expand the File Publish Options section and check the following boxes and click next:
    1. Delete all existing files prior to publish
    2. Precompile during publishing
  9. With Preview selected on the left, you are now ready to publish the web application. Click Publish

IIS Configuration

Application Pool: DefaultAppPool Sites:

  • ApplicationName – This represent the application. This should be mainly considered the front-end component of the overall application as it could be written using ASP.NET MVC or WebForms, Angular.js, Python, Ruby on Rails or any other web language. In our case we are building the application using ASP.NET MVC. Beyond that, the architecture was designed based on Domain Driven Design so there are more layers to the application other than just the MVC pattern. That means that when the application is built and deployed it will include the assemblies for other components.

  • ApplicationServices – This represents the service layer for the application. It takes advantage of the ASP.NET WebApi which is a REST service architecture. The front-end ASP.NET MVC application would communicate with the service layer using a Web Client and standard REST protocols. Builds & Deployments – Due to there being a Web Application component and a RESTful Services component IIS needs to be configured to have deployment containers for each. Below, you will find information on how to configure Visual Studio to deploy each of these so that you can run the application locally.

IIS Application Configuration

  1. Right click on Sites and select Add Website…
  2. In the Site Name field enter Application
  3. Click the Select... button and choose the DefaultAppPool
  4. Click the button next to the Physical path field and navigate to the location you create the Visual Studio publish profile. Example: C:\Projects\Deployments\Application
  5. Under the Bindings section leave all settings as they are but ensure that the Port is set to 80
  6. Click Ok

IIS Services Configuration

  1. Right click on Sites and select Add Website…
  2. In the Site Name field enter Services
  3. Click the Select... button and choose the DefaultAppPool
  4. Click the button next to the Physical path field and navigate to the location you create the Visual Studio publish profile. Example: C:\Projects\Deployments\Services
  5. Under the Bindings section leave all settings as they are but ensure that the Port is set to 81
  6. Click Ok

Developer Workflow

The following describes the workflow that a developer would exercise in working with not only the application framework but also in ensuring that they have the latest code and are committing code changes when it makes most sense. It is assumed that as a developer you understand how to create working folder on your developer machine so that you can pull the code from TFS and open it in Visual Studio to make changes, build and deploy the code locally. The code is structured just as the application architecture describes earlier in this document with the following outline.

  • Core
  • Data
  • Domain
  • Infrastructure
  • Services
  • Tests
  • UI

Beyond that, TFS has the following repositories which have a merge dependency between them. The merge relationship is such that once code is committed to the Development branch, development should be merged into QA. Once the code has been committed for that merge the code for QA can then be merged into the Production branch and then committed.

  • Development
  • QA
  • Production

If there are going to be multi developers working on this application then once one commits code to the development branch the other developer(s) should get the latest before developing any further. This will ensure that everyone on the team has the latest working code and there reduced surprises later.

Clone this wiki locally