mojoPortalAdvanced Web Sites Made Easy

As complicated as neccessary and no more. I forget who said that but I certainly agree. I write code in an Object Oriented style. For the most part when my user interface, the web site, interacts with my business objects, it will create an instance of the business object and interact with its properties and methods. In the data layer, by contrast you will see all static methods which it seems like I read is a called the facade pattern. Its purpose is to abstract the underlying database entirely away from the business layer.  This allows one to create data layers for multiple database platforms.

I generate much of the code in the business and data layer which saves enormous time on typical CRUD (Create, Retrieve, Update, Delete) operations. I always review the generated code and usually have to customize it if I need something other than basic CRUD.  I use CodeSmith Studio which is like using ASP.NET to generate your code including anything from stored procedures to user interfaces based on the database schema. I wrote my own scripts so I can point it at my MS SQL database and generate a corresponding data layer for MySQL, PostgreSql, Firebird Sql, or SQLite. I like this approach better than Object Relational Mapping.  I don't think the code should have to figure out at runtime what database platform is being used, that is a decision made before installation and I also like to be able to take advantage of whatever optimizations are supported by the given database.  In addition to that, I think simple straight forward data access code will be better for corporate developers who may wish to use mojoPortal as a starting point for additional development. They will use the version of the data layer for whatever is their standard database and the code they see in mojoPortal will be familiar to them.  I don't want them to have to learn an OR mapper to use mojoPortal, particularly because none are currently dominant and widely used in the .NET development world. Instead what you see is quite a few very nice OR mappers with fervent followers who think their particular OR mapper is the best.  I'm not saying this is bad or that OR mappers are bad, I'm just saying that the combination of pros and cons to me on balance does not make me want to use an OR mapper in mojoPortal and I think you will find the performance of mojoPortal to be very good on any of the supported databases because of the use of lightweight optimized data access code.

The whole web site is the presentation layer and therefore should only have code related to presentation logic. That is one of my goals in designing this framework. This web site was built using ASP.NET. It consists of:

• .aspx pages
• .ascx user controls
• a Global.asax file
• a Web.config file
• a Culture.config file
• mojoPortal.Web.dll, which contains all the presentation logic for the core framework

mojoPortal.Web.dll talks to mojoPortal.Business.dll and presents its interfaces to the user as web pages. The Web Site can run under Windows/IIS or under mono/Apache with most GNU/Linux distributions or Mac OS X.

When working in the web site I try to make sure that all of my code is presentation logic, providing a mapping between business object properties and methods to visual controls for intuitive user interaction.

All business logic for the core framework modules is handled by mojoPortal.Business.dll.

When developing in the business layer I try to think of the most natural way to represent or abstract business entities as objects in a way that can be easily consumed by the UI and then I map that to the database layer static methods. I don't see much value in creating a "data" object for my business layer to use. Static methods are guaranteed to be threadsafe by the runtime and this seems a very stable and efficient way to talk to the database.

All data access logic for mojoPortal.Business.dll is handled by mojoPortal.Data.dll. There are different versions of mojoPortal.Data.dll for each of the supported databases, MS SQL, MySQL, PostgreSQL, Firebird Sql, and SQLite. You can put any version in the bin folder of the web along with mojoPortal.Business.dll, and the site is happy as long as a valid database exists for the provided connection strings.

When developing in the data layer I try to think like the database and optimise operations according to its capabilities.