адавати ряд можливостей для користувальницького взаємодії (завантаження документів, оновлення, виклик форми редагування, сортування і т.д.). У зв'язку з цим був розроблений інтерфейс IOutcomeView, в числі можливостей якого наступні функції:
ReloadDocumentItems (DocumentItemTable table)
UpdateDocumentHeader (DocumentHeaderRow row)
UpdateDocumentEnabledState (Guid headerId, bool value)
SortAfterChangeDocumentType ()
ActivateTable (WorkMode mode)
ShowExportError ()
та інші.
Для управління бізнес-сутностями доменної області (з позиція інтерфейсу) був розроблений OutcomePresenter.
Серед основних можливостей даного класу можна виділити логіку зміни (редагування видаткових документів), завантаження і збереження в БД змін, логіка безпеки, допоміжні функції і «обгортки».
Для реалізації безпосередньо бізнес-логіки (доменної області) розроблявся під-модуль (фізично, це деякий набір відокремлених збірок) інкапсулює відносини/взаємодії між сутностями (в даному випадку видаткові документи, агенти, склади, користувачі, ролі, залишки, сутності інтеграції з різними сервісами і т.д.).
Для поділу управління і взаємодії між різними типами сутностей розробляються так звані менеджери:
· ImportSaleManager
· InternetSaleManager
· InventarizationManager
· OutcomeManager
· PriceChangeManager
· ReturnManager
· SaleManager
· TransferManager
· WholesaleManager
· WriteOffManager
Також розроблено ряд так званих «процесорів» для обробки різного роду звернень до бізнес-сутностей і спрощеного управління інформацією, що надається цими об'єктами:
DiscountProcessor
MultiPercentDiscountProcessor
TicketBasedDiscountProcessor
TimeBasedDiscountProcessor
Крім опису бізнес-сутностей і їх логіки, в моделі присутня опис всієї доменної інфраструктури (повідомлення, опису виключень т.д.).
На малюнку 5.1.1 показана модель відносин всіх бізнес-сутностей задіяних для реалізації даного модуля.
Рис. 6.1.1 Діаграма відносин бізнес-сутностей доменної області модуля видаткових документів
6.2 Реалізація
Реалізація будь-якого доменного функціоналу полягає в реалізації відповідного сервісу (або фасаду, агрегує ряд сервісів).
Реалізації відповідних сервісів поміщається в так звані об'єкти ресурси (Resource), що забезпечують весь необхідний back-end даного модуля.
Наведу деякі приклади таких реалізацій (ресурсів):
ImportSaleResource
InternetSaleResource
InventarizationResource
OutcomeResource
PriceChangeResource
І інші.
Для прикладу реалізації ресурсу, наведу вихідний код одного з методів:
override IEnumerable lt; WholesaleDocumentHeader gt; GetDocumentHeaders (int fromLocationCode, int toLocationCode, DateTimeRange period)
{response=_wholesaleService.GetImportSaleDocumentHeaders (GetDocumentHeadersRequest
{= period.From,=period.To,=fromLocationCode,=toLocationCode
}); response.Headers.Convert ();
}
Даний метод запитує у відповідного сервісу документи (заголовки).
Вищеописаний підхід дозволяє чітко розмежувати область відповідальності сервісу (який надає дані) від рівня програми (який додає свою фільтрацію і іншу логіку).
Графічний користувальницький інтерфейс представлений формою з табличним поданням видаткових документів (верхня таблиця) та поданням товарній частині відповідного (вибраного) документа (нижня таблиця).
Для реалізації таблиць використовувався пакет елементів управління від компанії ComponentOne (C1). Табличний елемент управління - FlexGrid.
Він кращим чином підходив всім потребам і демонстрував найкращі результати в плані продуктивності.
Інтерфейс користувача також надає можливості виклику діалогу редагування документа (заголовка) і товарів для даного документа.
Зовнішній вигляд для корис...
