The following images show diagrams of the platform at each version and
how each project related to one another at the time. You can see that
the core functional projects are tightly coupled together initially and
become more independent over time.
TODO: Create Image of 4.2
TODO: Import Image: DepMap-4.1.png
TODO: Import Image: DepMap-4.3.png
TODO: Import Image: DepMap-4.4.png
TODO: Import Image: DepMap-4.5.png
TODO: Create Image of 4.6
TODO: Create Image of 4.7
- HTML 5
- CSS 3
- LESS
- SASS
- Bootstrap 3.x Syntax
- JavaScript
- jQuery Syntax
- AngularJS Syntax
- TypeScript
- MS SQL 2012 R2
- EntityFramework 6.1.3
- C# .NET 4.5.2 (CEF 4.7 changed to 4.6.2)
- LINQ
- log4net
- StructureMap 3.x
- Lucene
- ServiceStack 4.0.38
- Newtonsoft.json 4.5
- xUnit 2
- TypeLite
- MS OpenXML API
- Google Docs API
- C# .NET 4.5.2 (CEF 4.7 changed to 4.6.2)
- Kendo UI (by Telerik) 2015.x
- JSON
- JavaScript
- TypeScript
- JQuery
- AngularJS
- Owin
- NPM
- Gulp
- Bower
- LESS
- CSS 3
- HTML 5
- Bootstrap 3.x
- Karma
- Jasmine
- DotNetNuke 7.x,8.x
- SiteFinity 8.1+
- WordPress
¶ Database and Access Technologies
- MS SQL Server 2012 R2+
- Due to the nature of EntityFramework, we could utilize any
number of database technologies such as MySQL or Oracle, however
Clarity specializes in Microsoft products
- Accessible by EntityFramework 6.1.3 calls (no direct SQL queries)
- CEF does not utilize any Stored Procedures to gather data into a
specific model
- EF is available free via NuGet
- EF Code First is used to generate a database schema from C# code
- Products are stored under Catalog.Product. This expands out to
Catalog.ProductXXXX where XXXX are things like Attributes,
Associations, Price Points, Variants, Media, Types.
- Categories are stored under Catalog.Category. This expands out to
Catalog.CategoryXXXX where XXXX are things like Attributes, Price
Points, Variants, Media, Types
¶ Version 4.3 and earlier
A specific pattern could not be identified for the solution as a whole,
the following short notation of the 5 primary layers indicates a pattern
similar to Repository, though Repository was not explicitly followed.
Db (Code first) <-> DAL (EF) <-> Business Logic (Workflows)
<-> Services (ServiceStack) <-> UI (Angular)
In each layer, code was written to perform the best possible outcome
with the least amount of writing. The process has been very organically
driven by customer requests over several years and worked by multiple
core team developers.
¶ Version 4.4 and later
Several patterns have been implemented:
- Inversion of Control (IoC): StructureMap allows us to determine the
concrete class at run-time and program directly to interfaces
instead
- Use of Generics: Generics allow us to write the code for a workflow
once and pass in any number of objects that would perform the same
actions. The primary usage is for standard CRUD operations, leading
to a Repository Pattern which will be implemented in 4.6.
- Data Mapper Pattern: Mapping between the Entity Model and Domain
Model occurs in a single Mapping DLL
- Unit of Work Pattern: Instead of saving on each individual change,
many changes are now grouped to a single, larger save to promote
continuity and transactional states
¶ Project Development Standards
¶ Coding Standards
- Code must pass StyleCop analysis with 0 warnings
- Exceptions on a Case-by-Case basis
- Code must pass Microsoft Managed Rules with 0 warnings
- Exceptions on a Case-by-Case basis
- Code must pass ReSharper Error analysis with 0 errors
- Exceptions on a Case-by-Case basis
- Code must pass ReSharper Warning analysis with 0 warnings
- Exceptions on a Case-by-Case basis
- Code must pass all Unit Tests written for it
- The Business Workflows Layer must have 98% Unit Test Coverage as
this is the most critical area to cover
- All other Layers must have 80% coverage
- Any valid Bug submitted for the platform must have a Unit Test
created that tests the expected result, to prevent regression by
future code
- Code must follow the Naming, Formatting, Layout, styles as specified
by the Clarity Shared ReSharper Settings
- See James G for a copy of these settings
- Code must not surpass a Cyclomatic Complexity threshold of 25
- In layman terms this means don't make any one function too big
as that is more difficult to maintain. Try to break the function
up into smaller functions called by a main in order if possible
- Exceptions on a Case-by-Case basis
- All code Properties, Fields, Enumerations, Classes, Functions, etc
must have full Summary Information Tags
- The tags may be generated by Atomineer as a minimum.
- Complex functions should have Remarks tags which explain
difficult to read or understand workflows,
- e.g.- code that can't self-document what it is doing very
well
- Tags should be compile-able by an external system such as
GhostDoc for creating Platform Documentation
- Exceptions on a Case-by-Case basis
- Abbreviation: CEF
- Name in Code: ClarityEcommerce
[] - Brackets indicate project or scenario specific name
<table>
<thead>
<tr class="header">
<th><p>Scenario</p></th>
<th><p>Format</p></th>
<th><p>Example</p></th>
<th><p>Notes</p></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><p>Database Name</p></td>
<td><p>CEF_[PROJECT_ABBREVIATION]</p></td>
<td><p>CEF_MCI, CEF_GAF</p></td>
<td></td>
</tr>
<tr class="even">
<td><p>Folder in DNN</p></td>
<td><p>\DesktopModules\ClarityEcommerce</p></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td><p>Angular Directives</p></td>
<td><p>cef-[directive]</p></td>
<td><p>cef-shopping-cart</p></td>
<td></td>
</tr>
<tr class="even">
<td><p>Namespaces</p></td>
<td><p>Clarity.Ecommerce</p></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td><p>Project Implementation Folder</p></td>
<td><p>C:\Data\Projects[PROJECT_ABBREVIATION]</p></td>
<td><p>C:\Data\Projects\MCI</p></td>
<td><p>Subfolders:</p>
<ul>
<li>_Archives</li>
<li>CEF</li>
<li>WEB</li>
</ul></td>
</tr>
<tr class="even">
<td><p>Visual Studio Solution Folder</p></td>
<td><p>Clarity.Ecommerce.[Component]</p></td>
<td><p>Clarity.Ecommerce.Services</p></td>
<td></td>
</tr>
<tr class="odd">
<td><p>Marketing space</p></td>
<td><p>Clarity eCommerce Framework</p></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td><p>SQL User Names</p></td>
<td><p>clarity, clarityuser</p></td>
<td></td>
<td><p>If a specific user is needed other wise use the standard user</p></td>
</tr>
<tr class="odd">
<td><p>HTML IDs</p></td>
<td><p>cef[Id]</p></td>
<td><p>cefCart</p></td>
<td><p>Use camelCase</p></td>
</tr>
<tr class="even">
<td><p>DNN Admin Skin Name</p></td>
<td><p>ClarityEcommerceAdmin</p></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
As the architecture does not currently define a strict pattern,
developers must at least adhere to the general guidelines of where to
put logic as defined by the Projects Outline. Core Schema code should be
present in the DataModel project, Business Logic in the Workflows
project, etc.
For more specific details, please contact James Gray.
- Clarity.Ecommerce: Contains core Utilities code, Enums and
Interfaces
- Clarity.Ecommerce.DataModel: Contains the Code-First Schema for
the Database
- Clarity.Ecommerce.Models: Contains Data Transfer Models
(Concretes)
- AuthorizeNET: Contains code for communicating with the
Authorize.NET payment processor API
- Clarity.Ecommerce.Integration: Contains code for communicating
with Tax Providers (such as Avalara), Payment Processors (such as
BNG) and Shipping Providers (such as UPS, FedEx)
- Clarity.Ecommerce.Workflow: Contains the core business logic for
the solution, such as retrieving Products that meet certain
criteria, calculating their prices and sending it off for use by the
Services layer
- Clarity.Ecommerce.Workflow.Test: Unit Testing for the Business
Logic, also contains other unit tests
- Clarity.Ecommerce.Service: ServiceStack services layer for
communication between the UI and the Business Logic
- ServiceStack.CodeGenerator.TypeScript: A TypeScript Generator
that reads the ServiceStack Services set up and creates TypeScript
ready code for convenient use of the Services API
- Clarity.Ecommerce.UI: The Core User Interface Angular Code,
common html templates and core CSS
- Clarity.Ecommerce.DNN: A DNN-specific CMS Installer for the
platform
- Clarity.Ecommerce.Demos: A SPA website which demonstrates the
functionality of the solution in a segregated environment (non-CMS)
- Clarity.Ecommerce.Demo.DNN: A DNN website which demonstrates the
functionality of the solution in a DNN CMS environment