Hotel project OO design

Recently, the company decided to rebuild all website projects using asp.net mvc. Although we did not participate in the reconstruction of hotel projects in the early stage, we have participated in the data layer and business logic layer of the hotel, I usually like to study some OO Knowledge, and occasionally arm the Code with the corresponding pattern in the project.

The most important data processing of hotel projects is divided into two types:

1: hotel search, which is divided into three types in detail:

<1>: search on the hotel list page

<2>: search on the hotel map page

<3>: search on the points Plaza hotel list page

Note: The above three search methods differ not only in parameters, but also in logic.

2: hotel order:

<1>: normal hotel order.

<2>: hotel order for point redemption.

 

Purpose:In order to better make the page UI Layer do not involve business logic, the decoupling is implemented based on the abstract factory concept. The detailed class diagram is as follows, which is not our common standard abstract factory model, but the idea is basically the same.

 

 

First, the underlying abstract factory class(Manage factories): Implements abstractfactory. It is mainly used to manage hotel search factories and hotel order factories. The following are two concreteFactory.

 

Code

Public abstract class implements abstractfactory
{
Public virtual ISearchHotel getsearchdomaininstance (descrirequestinfo request)
{
Return null;
}
Public virtual IOrderHotel getordersponinstance (descrirequestinfo request)
{
Return null;
}
Private static synchronized abstractfactory factory = null;

Public static response abstractfactory GetInstance (requestinfo request)
{
Switch (request. Fetch actiontype)
{
Case egion actiontype. Search:
Factory = new jsonsearchfactory ();
Break;
Case e1_actiontype. Order:
Factory = new vertex orderfactory ();
Break;
}
Return factory;
}
}

 

Second: hotel search Factory: Pull searchfactory, which will produce the hotel list page search factory, map page factory, etc., points square hotel list factory.

Code

Public class implements searchfactory: Implements abstractfactory
{
Public override ISearchHotel getsearchdomaininstance (descrirequestinfo request)
{
ISearchHotel search = null;
Switch (request. Condition Type)
{
Case eworkflow type. ForSimple:
Search = new searchbl ();
Break;
Case eworkflow type. ForMap:
Search = new searchformapbl ();
Break;
Case e1_type. ForSquare:
Search = new searchforsquarebl ();
Break;
}
Return search;
}
}

 

Third: hotel order Factory: Orders orderfactory, generate a normal hotel order factory, points Plaza order factory.

Code

Public class implements orderfactory: Implements abstractfactory
{
Public override IOrderHotel getordersponinstance (required requestinfo request)
{
IOrderHotel order = null;
Switch (request. Condition Type)
{
Case eworkflow type. ForSimple:
Order = new orders orderbl ();
Break;

Case e1_type. ForSquare:
Order = new orders orderforsquarebl ();
Break;
}
Return order;
}
}

Fourth: hotel search interface:ISearchHotel, which limits all search factories.

Public interface ISearchHotel
{
List <cmdinfo> GetHotelList (required requestinfo request );
 
}

 

Fifth: hotel order Interface: IOrderHotel, all hotel product order factories are subject to its constraints.

Public interface IOrderHotel
{
String InsertHotelOrder (Response reserveinfo request );
}

 

Sixth: Implementation of hotel search interfaces: Searchbl, searchformapbl, and searchforsquarebl.

Code

Public class implements searchbl: ISearchHotel
{
Public List <cmdinfo> GetHotelList (required requestinfo request)
{
List <shortinfo> sorted set = new List <shortinfo> ();
For (int I = 0; I <10; I ++)
{
Raise info = new raise info ();
Info. Consumer id = I;
Info. hotel name = "regular hotel" + I. ToString ();
Sorted set. Add (info );
}
Return sorted set;
 
}
 
}

 

7. Implementation of hotel order Interface: Orders orderbl, orders orderforsquarebl.

Public class implements orderbl: IOrderHotel
{
Public string InsertHotelOrder (Response reserveinfo request)
{
Return "the order is successfully placed at a regular hotel ";
 
}
}

 

Client call:

1: Call the hotel list data:

Code

// Search regular hotels
Required requestinfo request = new required requestinfo ();
Request. Required actiontype = emo-actiontype. Search;
Request. Pipeline type = epipeline type. ForSimple;
List <shortinfo> list = Response abstractfactory. GetInstance (request). getsearchdomaininstance (request). GetHotelList (request );

2: orders for ordinary Hotels:

 

Code

// Place an order at a regular hotel
Request = new response requestinfo ();
Request. Required actiontype = emo-actiontype. Order;
Request. Pipeline type = epipeline type. ForSimple;
Info = new response reserveinfo ();
Info. Consumer id = 1;
Result = Response abstractfactory. GetInstance (request). getordercontactinstance (request). InsertHotelOrder (info );

 

Advantages:

1: Multiple branches, but the method signature is uniform. for search, it will always let the user know GetHotelList. when placing an order, the user will only know InsertHotelOrder.

2: The UI dependency interface does not depend on the specific implementation. Modifying the logic of one of the branches does not affect other branches.

3: Through the abstract factory class, we can be very clear about the important interfaces of hotel projects.

Note:The above is just my design idea for a project. The picture is not detailed enough. Please give me more advice.

 

Author: Jiang min
Source: http://www.cnblogs.com/aspnet2008/