[Rainbowportal-devel] Ideas about new DAL layer

[Federico D. M. <if...@li...>]

I want to write some ideas about a new structure for Rainbow Data Access
LAyer and more.
Perhaps it maybe adopted in Rainbow 2

I think that data access architecture in current Rainbow version has 3 big
problems:
1. It is strongly linked to SQL Server
2. It is strongly linked to Module (Rainbow database structure is generated
by module installation. Each module create its table, stored procedure and
so on. For example if I want to create a new news module with some new
features I have to create a new table for news and I cannot use and share my
data with exist old news module. Because I must suppose that a new version
of old module would change its db structure. On the other hand it's hard to
create a new graphic interface for a exist news module)
3. It doesn't allow a simple OOP programming approach to Module programmer


The best way to solve these problems would be a O/R mapper data access
architecture like the java EJB or Hibernate.
But the .NET portings of these mappers are currently in alpha stage.
The NHibernate leader is missing (!) and project is stopping now.
The OJB project is still in pre-alpha stage.

So, I think we will not be able to play with a stable O/R mapper in the next
months and we will not program in pure OOP in every layer till next year...

To solve the 3 problems above I suggest to introduce in Rainbow system:
A. a new module data layer
B. a interface based (or abstract class based) data access layer

The new architecture (i.e. for news) maybe connected like this graph

UINewsModule1   UINewsModule2  UINewsModule3
      |               |              |
      +-------+-------+              |
              |                      |
       FedeDataNewsModule    ManuDataNewsModule
              |                      |
              +---------+------------+
                        |
                AbstractDALlayer
                        |
                        |
                    Database

A DataModule is a installable non-graphic module the expose a standard
interface for UIModules and on the other side calls the
AbstractDataAccessLayer.

For example the FedeDataNewsModule could expose methods like:

int AddNews(title, userId, text, expirationDate)
void DeleteNews(int newsId)
FedeNews[] GetThreeTopClickedNews(int newsCategoryId)
...

ManuDataNewsModule could expose different methods.

(Not IDataReader or IDataSet are passed to UIModule!)

FedeDataNewsModule call AbstractDALLayer methods to perform actions in ITS
db table
ManuDataNewsModule call AbstractDALLayer methods to perform actions in ITS
db table (usually different from FedeTables)


The UINewsModuleX is standard rainbow graphics module that use methods
expose by middle DataModule who it's linked to. They ignore the existance of
database.

The UINewsModule1 and UINewsModule2 is located in different pages and have a
different graphics structure and different user interface and behavior, BUT
they CAN modify the same set of news.


Using this architecture we can build a dynamic easy to understand structure
of site contents:

For example:

MySite
|
+-News (provided by FedeDataNewsModule)
|  |
|  +-Business news
|  |  +- publ. in HomePage using UINewsModule1
|  |  +- publ. in ShoppingPage using UINewsModule2
|  |
|  +-Customer news
|     +- publ. in WelcomeCustomer using UINewsModule2
|
+-News (provided by ManuDataNewsModule)
|  |
|  +-Company news
|     +- publ. in InternalHomePage using UINewsModule3
|
+-Forums (provided by ACMEDataForumModule)
|  |
|  +-Open discussion forum
|  |   +- publ. in DiscussionPage using HyperBitIncForumsModule
|  |   |
.  .   .
.  .   .

Each graphic module is linked to a specific type of data source module.

The installation process would be easy: if I install a new UImodule and his
DataModules (maybe more than one) don't exist the they will be installed
too.

I think this approach wuold be simplify our work. UIModule will be more
powerful, easier to create and db neutral.

We could think to create some UIModule specialized in data managed for a
specific DataModule, and so on...


The AbstractDAL is responsible of db neutral access. The DataModule create
SQL generic instruction and obtain IDataSet, IDataReader object.
I know this is not good like a SQL-Server stored procedure, but the system
can be extended to other database, and if in the future we will have a O/R
mapper we will have to modify only the database interface of DataModule and
nothing in UIModules.

I think that DAAB is a good first step for AbstractDAL.

 Fede_