-
Notifications
You must be signed in to change notification settings - Fork 3
Starting new project
For creating your project using composite UI download sources and includee Service.Infrastrucre project into your solution.
Each service has to has its own, unique keys, internal routing, request handler and view engine, so because they need to be generated. Because each of these components relies on service keys and some convention - that views for each service are deployed into ServiceNameService folder - they are generated by T4 text template. In order to add service you have to add service name to all of .tt files - this will automatically generate needed classes. Because you will have different project namespace, you should change namespace for internal routing in ServiceInternalRoutingConfig.tt to fits your project's namespace.
All routing registration in main web application needs to done via deriving from WebRouteRegistration if these routes are without area and via deriving from WebAreaRegistration if these routes are for area. These registrations creates WebRoute that is aware of service keys and can react on them.
Example of registering routes without area in main application:
public class RouteConfig
{
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.CreateRoute(
name: "Default",
namespaces: new[] { "CompositeUI.Web.Controllers" },
url: "{controller}/{action}/{id}",
defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
);
}
}Example of registering routes with area in main application:
public class TestAreaAreaRegistration : WebAreaRegistration
{
public override string AreaName
{
get
{
return "TestArea";
}
}
public override void RegisterArea(AreaRegistrationContext context)
{
CreateRoute(
context,
"TestArea_default",
"TestArea/{controller}/{action}/{id}",
new { action = "Index", id = UrlParameter.Optional }
);
}
}All routing registration in service web application needs to be done via deriving from ServiceAreaRegistration, because it will create ServiceRoute that is aware of service keys and can react on them. Each route within service has to register with unique prefix - for example service name - so routes without area will be registerd as area and routes with area will remain to be registerd as areas, but with specific prefix.
Example of registering service route without area:
public class CustomersAreaRegistration : ServiceAreaRegistration
{
public override string AreaName
{
get { return CustomersConsts.ServiceName; }
}
protected override string RouteServiceValue
{
get { return CustomersConsts.RouteServiceValue; }
}
public override void RegisterArea(AreaRegistrationContext context)
{
CreateRoute(
context,
CustomersConsts.ServiceName + "_service",
CustomersConsts.ServiceName + "/{controller}/{action}/{id}",
new { action = "Index", id = UrlParameter.Optional},
new[] { "CompositeUI.Customers.Web.Controllers" }
);
}
}Example of registering service route with area:
public class TestAreaAreaRegistration : ServiceAreaRegistration
{
public override string AreaName
{
get
{
return "TestArea";
}
}
public override void RegisterArea(AreaRegistrationContext context)
{
CreateRoute(
context,
CustomersConsts.ServiceName + "_TestArea_default",
CustomersConsts.ServiceName + "/TestArea/{controller}/{action}/{id}",
new { action = "Index", id = UrlParameter.Optional }
);
}
protected override string RouteServiceValue
{
get { return CustomersConsts.RouteServiceValue; }
}
}Each controller from main application should derive from WebController, as it defines methods for handling request, and each controller from service web application should derive from ServiceController, as it defines methods for returnig view models and handling request.
Service views are by default serached for in ServiceNameService folder in main web application folder for each service, so if you deploy them in other place, change ServiceViewEngine.tt file.
At the end you have to register needed infrastructure from service in main application dependency container. Define how each service will be signaled that application has started - for example using solution from Dependency injection section - and register implementation of IControllerActivator, IControllerFactory, generated by text template strongly named view engine and generated by text template strongly named request handler.
Use applications as if they were hosted on different machines. Enjoy :)
-
Welcome
1.1 Project overview
1.2 Features -
Introduction
2.1 UI composition example
2.2 Service separation
2.3 Service communication
2.4 UI composition goals
2.5 Clues how to start
2.6 Potencial problems -
Identifying widgets
3.1 Naming widgets
3.2 Widgets format
3.3 Amount of widgets
3.4 Widgets and service boundaries
3.5 Widgets and caching
3.6 Grid for widgets -
Delivering view models
4.1 Publishing request
4.2 Internal routing
4.3 Data in view models
4.4 Gathering view models -
Rendering view models
5.1 External routing
5.2 Including route values
5.3 Finiding physical view files
5.4 Template views - Getting data from request
- Sharing resources
- Service api
-
Transactions
9.1 One transaction
9.2 Multiple transactions
9.3 Transaction performance - Dependency injection
- Public api changes
- [Tables] (https://github.com/padzikm/CompositeUI/wiki/Tables)
12.1 Table order
12.2 Server-side rendering
12.3 Client-side rendering
12.4 Nested tables -
Cross-service validation
13.1 Server-side validation
13.2 Client-side validation -
CRUD
14.1 Service private data
14.2 Create
14.3 Update
14.4 Delete
14.5 Preview -
Caching
15.1 View models
15.2 Widgets
15.3 Pages - Optimizing network calls
- Scalling
- Client-side communication
- Deployment
- Starting new project