N-Tiered application
General description
N-tiered application is concept that allow to build very flexible applications. General idea here that from application to application concepts that used in each tier creation are the same.
Database
Concepts used on database creation:
- define tables
- define views
- define Stored Procedures API
- define access rules to data:
- used direct select, update, delete, insert T-SQL;
- used stored procedures;
 |
Best approach here is to use auto-generated TSQL by Visual Studio where possible and only in cases where required special logic use stored procedures. |
Naming rules
- Table always has name in multiple form, for example: Projects, Messages;
- each column in table has prefix that specify table, for example: projectId, messageType;
- Primary keys in most cases has name with suffix: Id;
- references on primary keys in other tables always has suffix Ref, for example: messageTableRef, taskProjectRef;
- names of references on primary keys is formed from three parts:
- table prefix;
- Reference table prefix;
- Ref marker - suffix;
- start names of Views with prefix vw;
Migration rules
- Use views instead of tables in cases where according to design possible future enhancements;
- Use suffix with number for each new version, for example: vwProjects2, vwTasks3; Pluses:
- much easier to enhance DAL layer;
- easier to control SELECT that forms view;
Data Access Layer (DAL)
Data access layer used for specifying API to DB. DAL API is very common to old C style API declarations; DAL can be used for data caching between DB ands Business Objects Layer (BOL). DAL can be used for encapsulation of database sever access method, for example: OleDB, ODBC, direct SQL Server providers and etc. Even if DAL not especially designed for caching in some cases DAL will do this function due to modules structure in N-tiered applications.
General features
- specify and store user information that trying to access DB data;
- specify and store time frame that used for DB data extracting, for example: show data from DB only on current year and do not try to access data older that period;
- specify additional parameters that are common for each query on DB level;
- define Typed Datasets;
- define table relations in datasets;
- define cleanup logic, for example: cleanup of cache;
- define multiple DB access protocols; for example: Online and offline modes;
- define security protocols of DB data access;
- check DB layer access/availability;
- data filtering according to general parameters (user, time frame, scope of logic operations, security permissions);
- data getting API must be "plain" without any deep hierarchy;
Business Objects layer
On this layer database data converted into business abstractions and logical actions. Here all data from DB converted to human language.
General functionality
- Create/Edit/Delete business object;
- extracting data from DAL for different kind of interpretation (read-only modes);
- import/export functionality from different sources;
- business logic algorithms/workflow implementation;
- reports/statistics extracting;
- hide from developer logic of database storing;
GUI object Layer
This is layer where Business objects represented to user by different views. They can be shown in any kind of GUI controls. Main idea here is to implement Data Binding and special logical dialogs.
Dialogs can be divided into several types:
- Add/Edit dialog.
- Add dialog in most cases can have a little more editable fields then Edit dialog.
- Add/Edit dialog have to implement one step Undo logic; (used Business Layer BeginEdit/EndEdit/CancelEdit logic);
- View dialogs
- special dialog that in different ways represent data and show it to user;
- very often such dialog allowed access to Edit/Add functionality;
- Delete operation often implemented as MessageBox that ask question and on it result choose required action;
- Administator interface - special dialogs that designed for:
- backup/restore operations;
- DB data integrity checking and fixing;
- DB data optimization;
- Import/Export functionality; (mostly used Business Layer XML/binary serialization/de-serialization);
- Security configuration:
- create/disable users;
- define user permissions;
General GUI features
- user interaction with Business objects;
- application errors processing;
- application and desktop/session interaction;
Implementation step-by-step
- design DB on SQL Server
- define stored procedures API;
- define access to DB data protocol;
- define private user data on DB that do not require synchronizations on each DB call;
- define common data that can be accessed/modified by multiple users at the same time;
- start new Visual Studio project
- create Typed Dataset that contains all tables from DB and relations between these tables;
- create special class will publish DAL API. Inherit this class from Component;
- in visual studio designer create SQLCommmand's, SQLConnection, SQLDataAdapters;
- define table mapping for each SQL Command;
- define parameters for each SQL Command;
- do not simplify WHERE part of the SQL Commands such complex structure helps in multi-user use cases;
- declare in class properties with common parameters, like: User Name, Password, DB Connection string, Time frame start/end;
- implement DAL API:
- methods return only DataView's or Typed DataSet, Typed DataRow;
- methods that implements UPDATE and DELETE logic has to take care about multi-user environments:
- use transactions if update/delete logic is complex and implemented by several queries; (for example DataAdapter.Update on DataTable must be in transaction);
- check @@ROWCOUNT SQL variable after each update/delete. This will allow to detect is action on data done correctly or not (see multi-user usage scenario for details; If @@ROWCOUNT return 0 (zero) then this mean that DB data was modified by another user and data must be refreshed first from DB and then current user apply modifications on it. In most cases these mean conflict that have to be resolved by user in interactive mode.)
- if in update/delete was error throw custom defined exception, inherited from ApplicationException;
- Internally in class exists only one DataSet that used by each API call for data extracting and updating;
- implement thread that will check DB server availability on time basis;
- ping of server by dummy SQL query;
- ping of server by ICMP protocol;
- ping of server by TcpIP SQL Server port check;
- create special class that will convert typed DataRows into Business Objects; such class mostly called BusinessObjectsFactory;
- implement in factory class business objects cache that will return on the same DataRow the same business object;
- implement cache on WeakReferences;
- implement cache cleanup logic by timer or by special user call;
- implement Business objects
- define common class for all business objects. On It implement such functionality:
- serialization/de-serialization binary and XML; (required for GUI layer)
- cloning; (required for GUI layer)
- BeginEdit/EndEdit/CancelEdit; (required for GUI layer)
- define typed business objects:
- transform DB data into business abstractions, like: enumerator, strings, language specific data-types and etc.
- implement Update logic of business object, specify DAL API method that update data on DB;
- implement New and Delete logic;
- define typed business objects collections:
- implement convert logic of the DataView into collection;
- implement convert logic of the DataRow array into collection;
- implement convert logic of the DataTable array into collection;
- implement convert logic of the typed versions DataRow and DataTable into collections;
- each item in collection have to be created by BusinessObjectsFactory class;
- define ROOT object in business hierarchy;
- define security logic and ROOT object creation protocol;
- define hierarchy on Business objects;
- try to exclude where possible cross-references on the same objects;
- in most cases data filtering allowing to get results from DAL cache instead of DB query; (for multi-user scenario this is potential problem that require special solution. Can be implemented special stored procedures on DB layer that can inform user was any data changes on DB or not. Most common way to implement such functionality is to create stored procedure that will return only differences of data instead of it whole scope.)
Short concepts
- business object is a wrapper on typed DataRow;
- all data physically in memory stored in Typed DataSet on Data access layer;
- security checks have to be implemented on each layer;
- errors processing have to be implemented on throw/try/catch/finally mechanism;
- do not try to make very common DB procedures that can be used in many use cases, better to implement wider and simpler API then short and complex;
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5