Which Items an inhouse-Framework should have
April 11, 2010 13 Comments
Title : Which Items an inhouse-Framework should have
Publish Date : 11/04/2010
Version : 1.0
Author : Nasser Hadjloo
Author Mail : email@example.com
Copyright (c) 2010 Nasser Hadjloo.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.
What is an in-house framework? A framework which a company developed for a or the rest of his software’s, to increase functionality and share common procedures in all of his software’s. Note that a company may have a bunch of frameworks which provided for different kinds of applications.
Which Items a Framework should have? This question has not a simple answer and in most cases we have to put on our in-house needs on it, but in most cases this framework should have some items which I’ll mention below. Note that you have to notice to your in-house needs to create an in-house framework and these items are not the only common items which your framework should have, these are only some of musts.
1- Each framework should contain system base classes which our applications should use. Note that these are most common base classes and each base class which uses in just a class shouldn’t be here.
2- Each framework should contain indeed Helpers which your company needs to use. For instance most of Iranian companies need a DateHelper which should convert Georgian calendar dates to Jalali dates.
3- Each framework should have some classes to provide access to database. For example these classes should give an entity and save/update/delete/etc it from/to database. Something which ORM’s do nowadays but for your in-house framework it’s not bad to have some similar class if you do not use an ORM.
4- Each framework should contain some Interface, abstract and other indeed enumerators which is common for all subsystems.
5- A framework may have some common exceptions classes which may use in your business classes. Note that an exception which will use once on the system shouldn’t be here.
6- Each framework should have a specific meaning, for example a developer should understand what your framework exactly can do?
The question which you may ask is that so where we should put our other classes which are not common? This is obvious; you have to put those in their application framework. The key point is that a framework will use in all of your subsystems and each application should have their own framework, so you have to put only common classes in the in-house framework and other indeed classes to their own application framework.
You can also add some other classes to your in-house application but note that they should be usable for the rest of your applications not only for a special application.