Дипломна работа Система за управление на инвестиционен портфейл Дипломант: Иван Драгоев, F09895 Ръководител: доц д-р Станислaв иванов

Exception Handling Application Block

Как да се обработи съответната грешка се указва във външен XML файл, позволявайки по всяко време да се смени стратегията за обработка.

Имплементация

Модел на базата данни

При създаване на нов обект в базата, като таблица или съхранена процедура, ще ми е нужно да знам типовете данни, които ще са ми необходими – реални числа, стрингове и т.н. Тук ще се ръководя от правилото, че за всеки логически тип данни ще дефинирам собствен тип. Например, за да съхраня стойност в смисъла на пари, ще дефинирам тип D_MONEY, който ще използва системния тип money. За полета, които представляват някакъв код, дефинирам D_CODE – nvarchar(25). Това въвежда едно ниво на абстракция и ни отделя от системно дефинираните типове. По този начин мигрирането от един сървър към друг става много по-лесно и единственото което е нужно, е да се създадат потребителските типове, като се използват подходящите за новия сървър системни типове. Например ако новият сървър няма тип money, тогава D_MONEY създавам базирано на numeric(14,4).

Друго правило е всяка таблица да има първичен ключ, който да се нарича ID е от тип D_ID (uniqueidentifier). За логическите първични ключове може да се създаде уникален индекс при необходимост.

Също така се стремя да създам база от данни, която да не позволява нарушаване на интегритета на данните. За целта използвам вторични ключове, индекси, тригери и т.н.

За всяка таблица създавам и съответното view, като при изпълнение на SELECT заявка използвам view-to. Не бива да имам извеждане на данни директно от таблица.

След като представих правилата, по които ще се водя при създаването на обекти в базата, мога да продължа с модела на данните за базовия модул, който е показан на диаграмата:

В таблицата COM_REGISTER се съхраняват всякакъв вид номенклатури, които ще бъдат групирани посредством GROUP_ID. Такива номенклатури ще са например типовете поръчки, статус на поръчките, и др. За тези данни, които са системни т.е. се използват и реферират от приложението, флагът IS_SYSTEM ще бъде установен на 1.

COM_INVESTOR таблицата съдържа данни за инвеститора. Един инвеститор може да има повече от един портфейл, а всеки портфейл има точно един инвеститор.

В таблицата COM_PORTFOLIO ще съхранявам данните за портфейлите. За момента имам само име на портфейла и връзка със инвеститора.

В COM_PORTFOLIO_ACCOUNT имам данни за паричните транзакции като например внасяния на средства по сметка на портфейла и т.н.

COM_PORTFOLIO_ORDER съхранява данните за сключените сделки, а COM_MARKET_MINDER за текущите котировки на даден актив.

Както е видно от модела на данните, нямам таблица, която да съхранява активите. Това е така, защото искам да постигна максимална независимост от актива и да не налагам конкретно описание. Затова навсякъде използвам ASSET_CODE като идентификатор на актива.

Всеки допълнителен модул, който добавя поддръжка на даден актив, може да има отделна таблица, която да дава детайлно описание на актива. Например за модула това ще е таблица, която съдържа данните за емитентите, където също има поле АSSET_CODE.

При добавяне на нов ред или промяна прибягвам до съхранени процедури с изключение на случаите, в които нямам допълнителна логика при тези операции както е например за таблицата COM_REGISTER.

Например за да добавя или променя данни в таблицата COM_MARKET_MINDER, трябва да използвам процедурата: SP_COM_UPDATE_MARKET_MINDER, която има следния код:

CREATE PROCEDURE [dbo].[SP_COM_UPDATE_MARKET_MINDER] (

@ASSET_CODE D_CODE,

@BID_PRICE D_MONEY,

@ASK_PRICE D_MONEY,

@LAST_TRADE_PRICE D_MONEY ) AS
DECLARE

@ID D_ID
SELECT @ID = ID

FROM VW_COM_MARKET_MINDER

WHERE ASSET_CODE = @ASSET_CODE

BEGIN

INSERT INTO COM_MARKET_MINDER

([ID], [ASSET_CODE], [BID_PRICE], [ASK_PRICE], [LAST_TRADE_PRICE])

VALUES

END

BEGIN

SET

ASK_PRICE = @ASK_PRICE,

LAST_TRADE_PRICE = @LAST_TRADE_PRICE

WHERE ASSET_CODE = @ASSET_CODE

END

Както се вижда от кода, процедурата проверява дали има съществуващ запис с указания код на актива. Ако не е намерен такъв запис, се създава нов и се попълва с данни от подадените параметри, а ако съществува – данните се актуализират с подадените.

SPM Solution

‘Shell’ проектът е стартиращият проект и генерира изпълнимия файл, който стартира системата. Той съдържа и главната форма както и основните workspace-и.

‘Common’ проектът съдържа всички общи за модулите части като константи, дефиниции на event handler-и и т.н. Всеки модул, генериран със Guidance Package автоматично добавя референция към този проект.

След като имам създадена основната структура на проекта, я добавям към системата за сорс контрол – в случая – Visual Source Safe – това ще позволи съхранението на различни версии на програмата. Трябва да се има предвид, че в системата за сорс контрол трябва винаги да се слагат версии, които са компилируеми.

Проект Common

В Common проекта на SPM системата ще добавя и поддиректории за бизнес обектите и за услугите, които ще са общи за модулите. За целта създавам два класа – BusinessObjec и BaseService, които ще бъдат наследени от всички бизнес обекти и услуги:

public class BusinessObject

{

}

public class BaseService

{

}

Атрибутът [Service] указва, че класът е услуга и при наличие на същия атрибут върху свойство на клас от MVP шаблона, CAB ще го инициализира вместо нас, като ще създаде инстанция на самия service, ако няма или ще използва вече създадената инстанция.

public class DataBusinesObject : BusinessObject

{

public DataSet Data

get{ … }

{

get{ … }

{

get{ … }

{

…

}

Този клас получава в конструктора си DataSet, който съдържа данните с които оперира бизнес обектът. Вторият параметър служи за задаване име на обекта, който да бъде свързан към BindingSource-а. Този BindingSource служи за свързване на визуалните контроли с бизнес обекта. Той е особено полезен при бизнес обекти, които по същество са списъци, тъй като пази информация за текущо избрания елемент от списъка.

public class DataService

{

private static DataService instance;

{

get

if( instance == null )

instance = new DataService();
return instance;

}

}

{

this.database = DatabaseFactory.CreateDatabase( "SPM" );

}

Интересното тук е, че този клас имплементира шаблона Singleton. Този шаблон се използва в случите когато искаме да имаме само една инстанция от даден клас. Тук това е постигнато чрез статичното свойство Instance и скрит конструктор.

Тук се вижда как се регистрира поддръжката на дадена база, а по-надолу и конкретното използване, както и задаването на параметрите, необходими за установяване на връзка с конкретната база.

Проект Shell

В моя случай основната област е разделена на две области, наречени MainLeftWorkspace и MainContentWorkspace.

MainLeftWorkspace е от тип DeckWorkspace и е предназначена да съдържа контроли, които са общи за програмата, независимо от модула, с който се работи.

MainContentWorkspace е от тип TabWorkspace. В тази област се показват различни view-та от заредените модули, като за всяко view се създава отделна страница – tabpage.

Важен е и файлът ‘ProfileCatalog.xml’, който съдържа конфигурацията на системата . В него се описват модулите, които ще бъдат заредени, както и други опции, които могат да бъдат прочетени от приложението.

Проект CommonModule

• 
  Module – наследникът на класа ModuleInit от CAB фреймуърка. Този клас е входната точка на модула и той ще бъде инстанциран при стартиране на приложението;
  
• 
  ModuleController – наследникът на класа WorkItemController. Съдържа методи за инициализиране на модула като: services, елементи на потребителския интерфейс и т.н.;
  
• 
  Класове в поддиректория ‘Constants’ – в тази поддиректория се съхраняват класове с различни константи – за събитията, за командите, за иментата на Workstpaces и др.
  

Бизнес обекти

Всички те са наследници на класа, дефиниран в Common модула DataBusinessObject.

Освен тези обекти в директорията има още два специфични класа-PortfolioOverviewCalculator и PortfolioOverviewCalculatorList. Първият клас е абстрактен и дефинира интерфейс за калкулатори, които ще се визуализират от PortfolioOverview SmartPart-a. Тези калкулатори имат за цел да изчисляват някакъв показател:

public abstract class PortfolioOverviewCalculator

{

public PortfolioOverviewCalculatorList CalculatorList

get{ … }

{

get;

{

get;

{

…

}

Наследниците на този клас трябва да имплементират абстрактните свойства и методи. Свойството Name дава името на показателя, който се изчислява от калкулатора, методът Calculate() извършва изчислението, a чрез свойството ResultAsString се взима стойността.

Услуги (Services)

Тези услуги използват инстанцията на DataService, който е имплементиран в Common модула, и предоставя връзка към базата. Една имплементация на метод за зареждане на данни е дадена по-долу:

public DataSet Load( Guid portfolioId )

{

DbCommand command;

command = DataService.Instance.Database.GetSqlStringCommand(

string.Format( "SELECT * FROM {0}", TableNames.PortfolioOrderView ) );

else

command = DataService.Instance.Database.GetSqlStringCommand(

string.Format( "SELECT * FROM {0} WHERE PORTFOLIO_ID = @PORTFOLIO_ID", TableNames.PortfolioOrderView ) );

DataService.Instance.Database.AddInParameter( command, "@PORTFOLIO_ID", DbType.Guid, portfolioId );

}
DataSet dataSet = DataService.Instance.Database.ExecuteDataSet( command );

dataSet.Tables[ 0 ].TableName = TableNames.PortfolioOrderView;

return dataSet;

}

Първо се създава обект от тип DbCommand, който пресъздава заявка към базата. Проверява се стойността на подадения параметър – portfolioID и ако е валиден идентификатор, данните се ограничават по този идентификатор - иначе се зареждат без никакво условие за ограничение. Резултатът от изпълнението на командата е DataSet, който съдържа една таблица, на която указвам име, след което връщам DataSet-а като резултат.

SmartParts

Чрез MVP шаблона се постига разделение на отговорностите по визуалното представяне и обработката на събитията в отделни класове. Класът, който е отговорен за визуалното представяне, се нарича View, а класът, който обработва събитията, се нарича Presenter. View класът предава събитията на Presenter класа, който има логиката за обработка на конкретните събития, и в резултат може да промени състоянието на View класа. От своя страна, Presenter класът използва ‘модела’ (често това е бизнес обектът), за да отговори на дадено събитие:

За удобство, Guidance Package-ът създава за нас View клас, наследник на UserControl, Presenter клас, както и интерфейс, който се използва за комуникация помежду им:

[SmartPart]

public partial class OrdersView : UserControl, IOrdersView

{

…

}

{

…

public interface IOrdersView

{

…
}

PortfolioSelectorView

Тук под команда се разбира имплементация на шаблона command. В нашия случай това става като се имплементира event-handler, на който се маркира със специалния атрибут [CommandHandler( )] и който в конструктора си приема параметър името на командата. Когато на presenter класа на това view се инициализира с инстанция на WorkItem, се извиква метода ExtendMenu(), който добавя в менюто на workitem-a командите за добавяне, редактиране и изтриване на портфейл:

public class PortfolioSelectorViewPresenter: IDisposable

{

…

{

ToolStripMenuItem item = new ToolStripMenuItem( Properties.Resources.Portfolios );

_workItem.UIExtensionSites.RegisterSite( UIExtensionSiteNames.MainMenu_Portfolios, item.DropDownItems );

_workItem.Commands[ CommandNames.AddPortfolio ].AddInvoker( item, "Click" );

_workItem.UIExtensionSites[ UIExtensionSiteNames.MainMenu_Portfolios ].Add( item );

…

}

}

Първо се създава менюто, което ще съдържа подменюта, изпълняващи командите. След това се създава menu item за всяка една команда, извиква се методът AddInvoker на командата, като подаваме новосъздадения menu item и събитието, което да предизвика изпълнение на командата – в случая Click.

Публикуването на събитие става по следния начин:

[EventPublication( EventTopicNames.PortfolioChanged, PublicationScope.Global )]

public event EventHandler> PortfolioChanged;

Отново това публикуване става с помощта на атрибут и това е атрибутът [EventPublication]. Като параметри на неговия конструктор се подават името, под което искаме да бъде публикувано това събитие в системата, както и обхвата – за цялата програма, за наследниците или за WorkItem-а.

При визуализиране на портфейлите се използва контролата DataGridView, която се свързва към BindingManager свойството на обекта PortfolioList, който играе ролята на бизнес обект. Текущо активираният портфейл е маркиран в плътно синьо.

PortfolioOverView

PortfolioMarketMinderView

PortfolioMarketMinderView визуализира данните за текущите цени на активите в портфейла. В него в табличен вид са показани цените ‘купува’ и ‘продава’, както и цената, при която е сключена последната сделка. Под последна сделка имам предвид не за портфейла, а за пазара, на който се търгува конкретният актив.



Фиг. 18

Тук потребителят може сам да въведе информацията за цените на активите,които ще бъдат съхранени в базата. Това позволява, дори и при отсъствието на модул за актуализиране на цените в реално време, потребителят да въвежда сам актуалните цени, които се използват при изчисление на параметрите в останалите view-та – това с обобщената информация и детайлите. Естествено, за да стане това, има публикувано събитие, за което са се регистрирали и двата модула.

PortfolioLeftPanelView

Предназначението на това view е да бъде контейнер на PortfolioSelectorView, PortfolioOverView и PortfolioMarketMinderView, като го подрежда в този ред. От своя страна, то е вградено в MainLeftWorkspace на главната форма.

PortfolioDetailsView

Тук се показват детайлизирано данните за портфейла. Това са данни за всички активи, които са или са били част от портфейла. Тук потребителят може да види за всеки актив какво количество е било закупено, какво има в наличност, средно претеглена цена на придобиване, реализираната печалба и т.н.

Тези данни са базирани на данните за цена на последната сключена сделка, регистрирана в Market Minder-а, и от сключените сделки се актуализира при всяка промяна в цената или в списъка със сделките.

Потребителят има още възможност за филтриране по актив, както и да сортира данните. Това view е само за четене и изглежда по следния начин:



Фиг. 19

За улеснение първата колонка – кода на актива, е фиксирана и при хоризонтално скролиране тя остава винаги видима. Потребителят може да сортира данните по всяка една колона, като кликне с левия бутон на мишката върху името на колонката, по която иска да се извърши сортировка.

PortfolioOrdersView

Сключените сделки се показват в това view. Потребителят има възможност за сортировка, както и за добавяне, редактиране и изтриване на сделки.



Фиг. 20

PortfolioContextView

Също както и PortfolioLeftPanelView, това view е композитно и съдържа PortfolioDetailsView и PortfolioOrdersView. Визуализира се в MainContentWorkspace на главната форма.

При стартиране на програмата се отваря главният прозорец, който изглежда така:

Фиг. 21

News Module

Този модул служи за доставяне на новини, които се получават от web-service. За целта потребителят трябва да е абониран за тази услуга, която обикновено се хоства на сървъра на инвестиционния посредник, на когото той е клиент.

Този модул всъщност се състои от няколко части – сървърна част, web service и клиентски модул.

Сървърната част служи за въвеждане на новините в базата на посредника. Тази част е подобна на клиентския модул с разликата, че позволява въвеждане на новина. Тъй като разликата от клиентския модул е само наличието на форма за въвеждане на новина, която по същество не се различава от останалите форми за редактиране на данни в останалите модули, тази част няма да бъде разглеждана. Ще отделя повече внимание на самия процес, не на получаване на новините.

Проект NewsModulwWebService

Web service частта предоставя услугата за получаване на новини, като се публикува на web сървър. След като се публикува, услугата е достъпна за клиентския модул, който на определен интервал от време запитва за наличието на новини, и ако има новини с дата по-голяма от датата на последната новина в базата на клиента, се прави заявка за новите новини.

За да създам web услуга, в средата на Visual Studio използвам шаблон за проект от типа ASP.NET Web Service, който изгражда инфраструктурата на самата услуга. В резултат имам генериран файл Service.cs, който съдържа кода, файл Service.asmxm който указва типа и файла с имплементацията на услугата. Чрез този файл компилаторът знае къде се намира класът с имплементация на услугата и го компилира при първата заявка към услугата. Във версия 2.0 на ASP.NET не е нужно да се слагат компилирани версии на web приложенията. Достатъчно е да се сложат файловете с кода и сървърът сам ще ги компилира.

В случая Service.asmx файла съдържа:

<%@ WebService Language="C#" CodeBehind="~Service.cs" Class="NewsModuleService" %>

За да имплементираме web service-а, средата създава за нас наследник на класа WebService, който е базов клас за XML web service и предоставя достъп до основни обекти от ASP.NET като сесия и т.н. Към този клас добавям два метода - HasNews и Search.

Методът HasNews приема за параметър дата и час и проверява в базата за наличието на новини с дата и час по-големи от зададената. Ако има такива, връща true иначе false:

[WebMethod]

public bool HasNews( DateTime dateTime )

{

return new NewsService().HasNews( dateTime );

}

Вижда се, че се извиква метод на NewService, който използвах и в модула NewsModule. А ето и имплементацията на NewsService.HasNews() метода:

public bool HasNews( DateTime dateTime )

{

DbCommand command = DataService.Instance.Database.GetSqlStringCommand(

string.Format( "SELECT COUNT(*) FROM {0} WHERE REC_DATE > @REC_DATE", TableNames.NewsView ) );

DataService.Instance.Database.AddInParameter( command, "@REC_DATE",

DbType.DateTime, dateTime );
int result = (int)DataService.Instance.Database.ExecuteScalar( command );

return result > 0;

}

Тук с помощта на Data Access Application Block създавам команда, инициализирам я със заявка, която да ни върне броя на новините с дата по-голяма от подадената като параметър. Извиквам метода ExecuteScalar, който взима резултата от първия ред – първата колона и ми го връща като обект, който в моя случай е от тип integer. Ако резултатът е по-голям от 0, тогава имам налични новини и връщам true.

Другият метод на услугата е методът Search и има следната имплементация:

[WebMethod]

public DataSet Search( DateTime fromDate, DateTime toDate, string code,

string category, string source, string subject, string fullText)

{

object fromDate_param = DBNull.Value;

object toDate_param = DBNull.Value;

object code_param = DBNull.Value;

object category_param = DBNull.Value;

object source_param = DBNull.Value;

object subject_param = DBNull.Value;

object fullText_param = DBNull.Value;

if(fromDate != DateTime.MinValue)

fromDate_param = fromDate;

if(toDate != DateTime.MinValue)

toDate_param = toDate;

if(code != string.Empty)

code_param = code;

if(category != string.Empty)

category_param = code;

if(source != string.Empty)

source_param = code;

if(subject != string.Empty)

subject_param = code;

if(fullText != string.Empty)

fullText_param = code;

NewsService service = new NewsService();

return service.Search( fromDate_param, toDate_param, code_param,

category_param, source_param, subject_param, fullText_param );

}

Тъй като при подаване на параметрите се използва сериализация, съм избрал те да са типизирани. Имплементацията на метода Search от NewsService приема същите параметри като семантика, но типът им е object. Това е така защото мога да задам стойност на параметъра DBNULL.Value което съответства на NULL в базата данни, а DB>NULL.VALUE не е съвместим със string или DateTime. От друга страна, при сериализацията на параметрите има проблем при нетипизираните параметри – параметри от тип object. Ето и самото търсене:

public DataSet Search( object fromDate, object toDate, object code, object category, object source, object subject, object fullText )

{

DbCommand command = DataService.Instance.Database.GetSqlStringCommand(

string.Format(

"SELECT * " +

"FROM {0} " +

"WHERE (@FROM_DATE IS NULL OR @FROM_DATE <= REC_DATE) AND "+

" (@TO_DATE IS NULL OR REC_DATE <= @TO_DATE) AND "+

" (CODE LIKE ISNULL(@CODE, N'%')) AND " +

" (CATEGORY LIKE ISNULL(@CATEGORY, N'%')) AND " +

" (SOURCE LIKE ISNULL(@SOURCE, N'%')) AND " +

" (SUBJECT LIKE ISNULL(@SUBJECT, N'%')) AND " +

" (FULL_TEXT LIKE ISNULL(@FULL_TEXT, N'%'))", TableNames.NewsView ));

DataService.Instance.Database.AddInParameter( command, "@FROM_DATE",

DbType.DateTime, fromDate );

DataService.Instance.Database.AddInParameter( command, "@TO_DATE",

DbType.DateTime, toDate );

DataService.Instance.Database.AddInParameter( command, "@CODE",

DbType.String, code );

DataService.Instance.Database.AddInParameter( command, "@CATEGORY",

DbType.String, category );

DataService.Instance.Database.AddInParameter( command, "@SOURCE",

DbType.String, source );

DataService.Instance.Database.AddInParameter( command, "@SUBJECT",

DbType.String, subject );

DataService.Instance.Database.AddInParameter( command, "@FULL_TEXT",

DbType.String, fullText );

DataSet dataSet = DataService.Instance.Database.ExecuteDataSet( command );

dataSet.Tables[ 0 ].TableName = TableNames.NewsView;

return dataSet;

}

Тук най-интересното е самата заявка към базата. За да се игнорират параметрите, които имат стойност NULL, правя следното:

@PARAMETER_1 IS NULL OR [] operator @PARAMETER_1

Тук идеята е да се направи проверка за NULL и с ‘OR’ да се направи същинската филтрация по параметъра. Така, ако стойността е NULL, тогава изразът връща true и параметърът се игнорира. Ако пък има стойност, различна от NULL, се прилага втората част от израза. Тук ‘operator’ е всякякъв валиден оператор за сравнение.

Както е видно от имплементацията на методите в web service-а, методите, които искаме да бъдат публикувани, се маркират с атрибута [WebMetod]. Той прави видим за XML метод видим за отдалечените web клиенти на услугата.

Проект NewsModule

Този проект представлява клиентската част, който се интегрира във SPM системата и която прави запитвания към услугата за новини.

За целта е имплементиран service – NewsUpdateService, който на определен интервал от време проверява за наличието на новини, и ако има такива, актуализира клиентската база. А ето и дефиницията на класа:

public class NewsUpdateService

{

public NewsUpdateService(){…}

public void Start(){…}

public void Stop(){…}

public bool HasNews(){…}

public bool Update()

{

if( this.HasNews() == false )

return false;
NewsService newsService = new NewsService();

DataSet dataSet = newsModuleserver.Search(

newsService.GetLastNewsDate(),

DateTime.MinValue, string.Empty,

string.Empty, string.Empty, string.Empty, string.Empty );
newsService.ForceSave( dataSet );
return true;

}

}

Класът съдържа базова функционалност, необходима за управление на синхронизацията – методи за стартиране и спиране на проверката за новини и метода Update за актуализиране.

За да може да извиквам методи на web service-а, съм създал web reference към самия service. За мен, средата на Visual Studio генерира proxy, което има интерфейса на истинския web service. По този начин се улеснява работата с web service, тъй като за мен той по нищо не се различава от обикновен клас.

В метода Update първо извиквам метода HasNews, който извиква метода HasNews на web service-а. Ако в резултат имам true, тогава се извиква и методът Search на web service-a с параметър датата и часа на последната новина в базата на клиента. Тази дата се взима чрез метода GetLastNewsDate.

В резултат получавам DataSet, който съдържа в себе си една таблица с новините. Тези новини сега трябва да се запишат в клиентската база. За да направя това, е нужно да извикам съхранена процедура за всеки ред от таблицата в DataSet-a. Тук не мога да приложа стандартния подход, в който създавам команди за insert, update и delete, защото данните в таблицата не са променяни и следователно няма как да бъдат записани в базата.

За тази цел съм имплементирал метода ForceSave, който има следния вид:

public void ForceSave( DataSet dataSet )

{

DbCommand insertUpdateCommand = this.GetInsertUpdateCommand();

foreach( DataRow row in dataSet.Tables[ TableNames.NewsView ].Rows )

{

insertUpdateCommand.Parameters["@ID"].Value = row["ID"];

insertUpdateCommand.Parameters["@REC_DATE"].Value = row["REC_DATE"];

insertUpdateCommand.Parameters["@CODE"].Value = row["CODE"];

insertUpdateCommand.Parameters["@CATEGORY"].Value = row["CATEGORY"];

insertUpdateCommand.Parameters["@SOURCE"].Value = row["SOURCE"];

insertUpdateCommand.Parameters["@SUBJECT"].Value = row["SUBJECT"];

insertUpdateCommand.Parameters["@FULL_TEXT"].Value = row["FULL_TEXT"];

DataService.Instance.Database.ExecuteNonQuery( insertUpdateCommand );

}

}

Вижда се как в цикъл се изпълнява команда, получена чрез извикване на метода GetInsertUpdateCommand(). На командата се указват стойности на параметрите от конкретния ред от таблицата, след което тя се изпълнява. Самата команда се създава така:

private DbCommand GetInsertUpdateCommand()

{

DbCommand insertUpdateCommand =

DataService.Instance.Database.GetSqlStringCommand(

StoredProcedureNames.AddUpdateNews );

insertUpdateCommand.CommandType = CommandType.StoredProcedure;
DataService.Instance.Database.AddInParameter( insertUpdateCommand, "@ID",

DbType.Guid, "ID", DataRowVersion.Current );

DataService.Instance.Database.AddInParameter( insertUpdateCommand, "@REC_DATE",

DbType.DateTime, "REC_DATE", DataRowVersion.Current );

DataService.Instance.Database.AddInParameter( insertUpdateCommand, "@CODE",

DbType.String, "CODE", DataRowVersion.Current );

DataService.Instance.Database.AddInParameter( insertUpdateCommand, "@CATEGORY",

DbType.String, "CATEGORY", DataRowVersion.Current );

DataService.Instance.Database.AddInParameter( insertUpdateCommand, "@SOURCE",

DbType.String, "SOURCE", DataRowVersion.Current );

DataService.Instance.Database.AddInParameter( insertUpdateCommand, "@SUBJECT",

DbType.String, "SUBJECT", DataRowVersion.Current );

DataService.Instance.Database.AddInParameter( insertUpdateCommand, @FULL_TEXT",

DbType.String, "FULL_TEXT", DataRowVersion.Current );

return insertUpdateCommand;

}

Командата, върната като резултат от метода GetInsertUpdateCommand, е базирана на съхранената процедура SP_NWS_ADD_UPDATE_NEWS. Тази съхранена процедура има следния вид:

CREATE PROCEDURE SP_NWS_ADD_UPDATE_NEWS(@ID D_ID,

@REC_DATE D_DATETIME, @CODE D_CODE, @CATEGORY D_NAME,

@SOURCE D_DESCRIPTION, @SUBJECT D_DESCRIPTION,

@FULL_TEXT D_MEMO ) AS

IF NOT EXISTS (SELECT ID FROM NWS_NEWS WHERE ID = @ID)

BEGIN

INSERT INTO NWS_NEWS

(ID, REC_DATE, CODE, CATEGORY, SOURCE, SUBJECT, FULL_TEXT)

VALUES

(@ID, @REC_DATE, @CODE, @CATEGORY, @SOURCE, @SUBJECT, @FULL_TEXT)

END

ELSE

BEGIN

UPDATE NWS_NEWS

SET

REC_DATE = ISNULL(@REC_DATE, REC_DATE),

CODE = ISNULL(@CODE, CODE),

CATEGORY = ISNULL(@CATEGORY, CATEGORY),

SOURCE = ISNULL(@SOURCE, SOURCE),

SUBJECT = ISNULL(@SUBJECT, SUBJECT),

FULL_TEXT = ISNULL(@FULL_TEXT, FULL_TEXT)

WHERE ID = @ID

END

В процедурата, както се вижда от кода, първо се проверява дали вече не съществува новина със зададеното @ID. Ако такава новина няма, тогава се добавя в базата нов запис. При наличие на новина със същата стойност на първичния ключ, се актуализират нейните полета.

Заключение

Така създадената система, дори и в базовата си конфигурация, предоставя на потребителя достатъчна функционалност, за да може той да бъде информиран за текущото състояние на активите си. Системата също така подпомага и инвестиционните посредници при управлението на доверителните портфейли. Тъй като програмата не е ограничена до даден набор от активи, тя е приложима за всякакъв вид инвестиции.

Имплементирана на модулен принцип на практика означава, че във всеки момент могат да бъдат добавени неограничен брой модули, което означава и нова функционалност

Конфигурирането на база модули позволява да се удовлетворят желанията на различните потребители.

Библиография

Попов. Д.. Ценни Книжа и фондови борси. София, СИЕЛА – Софт анд пъблишинг, 2000, 367 с.

Левинсън, М. Финансови пазари – пътеводител. София, Класика и Стил, 2004, 326 с.

Бенсингър, Р. Нови идеи в техническия анализ. София, Класика и Стил, 2004, 310 с.

Фаулър, М. UML основи – кратко ръководство за стандартния език за обектно моделиране. София, СофтПрес, 2004, 204 с.

Гама, Е., Хелм, Р., Джонсън, Р., Влисидес, Д. Design Patterns., София, СофтПрес, 2005, 464

Интернет източници

Уикипедия, свободната енциклопедия - www.wikipedia.org

Инвестор БГ - www.investor.bg

www.investopedia.com

Вестник Капитал - www.capital.bg

Вестник Дневник - www.dnewnik.bg

Вестник Сега - www.segabg.com

Инвестиционен посредник Карол - www.karoll.net

Инвестиционен посредник Елана - www.elana.net

Microsoft Developer Network - msdn.microsoft.com

Microsoft Developer Network/Pattern&Practices - msdn.microsoft.com/practices

1 Попов Д, ‘Ценни книжа и фондови борси, СИЕЛА софт анд паблишинг, 2000г

1 www.wikipedia.org

2 www.segabg.com

1 www.segabg.com

2 http://www.investor.bg/?id=37033

3 Диверсификация – разпределяне на риска, като се инвестира в различни насоки – акции, облигации, недвижима имущество или различни индустрии.

1 CAB Help documentation

1 http://msdn.microsoft.com/practices/apptype/smartclient/default.aspx?pull=/library/en-us/dnpag2/html/cab.asp

2 Пак там

1 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/entlibjan2006_dataaccessappblock.asp

София, 2006

Изтегляне 0.56 Mb.

Сподели с приятели: