Best way to build websites or applications with modular / reusable components

Question

If I come to the point where I get a job that has almost identical requirements as a previous job, I try my best to reuse and repurpose previous work.

It is never that easy and it usually takes some time (but not as long as redoing it from scratch!)

Anyway, I have a few jobs coming up where they need identical login systems. Where as previously I would have created a site for the project, then a new folder for the login system, this time I have made a whole project just for the login system.

I could easily use this as a base, then copy and paste to my future projects and adapt it to them - however, I would really like to be able to just maintain this one release and add to future projects when needed (and improve then release to all projects using it).

I have tried to sum up what it is I am trying to achieve. There are a lot more components that can be reused across my projects which is why I really want to understand how to build this way.

My biggest worry and question is about databases - Every component needs to have a database. I have created the schema for the login system and have given all tables a prefix, however, if each component has its own database, how do I move them all to one at the end?

Sorry if I have been confusing, I will be happy to sum anything up or respond to comments - I am hoping someone can basically give a guide to best practices or books that can help me achieve this as I am hoping it could save me significant time in the future to maintain components independently of the projects that need them.

Answer 1

My biggest worry and question is about databases - Every component needs to have a database. I have created the schema for the login system and have given all tables a prefix, however, if each component has its own database, how do I move them all to one at the end?

Which is why you need to have a DAL to specifically handle the database. This DAL will be different from one project to another, for sure. But you can use interface to give them common operations that your controller can call to.

For example, make sure that your admin class inherits from IAdminBusiness:

public interface IAdminBusinessClass
{
   bool Login();
   Reset Password();
}

public class AdminBusinessClassForProjectA: IAdminBusinessClass
{
  // implement the interface
}

Now, in your AdminController, which is the same across different projects, you can thus write:

public Class AdminController
{
  public IAdminBusinessClass businessAdmin
{get;set;}

  public Response Login(string username, string password)
  {
    // implement your controller logic here, which is common across diff databases and projects
  }
}
}

The key thing is to break things down into modular components, and use Interface for the variable components.

Answer 2

Are you sure you want to be writing your own login system? If you're using a web app framework (which is a collection of "modular/reusable components") such as Spring MVC, Ruby on Rails, or Symfony, you should have a user login system available as part of the framework or as a plugin.

In fact, there are enough hairy security issues involved in doing session authentication securely that unless you have a really compelling reason for rolling your own, you're probably much better off using a well-tested package than rolling your own, even if you're a security wizard.

Answer 3

What you want to set-up is a Software Product Line (SPL), based on reusable assets. These reusable assets have to configurable, managed, and should easily "snap" into other parts of your system. Essentially you need to do MDSD (Model-Driven Software Development), or DSM (Domain-Specific Modeling)... Yep, a pile of acronyms, but an exciting new future nonetheless.

I suggest you have a look at ABSE (Atom-Based Software Engineering). ABSE is a new approach to MDSD that fits in what you want to achieve. Its official site is at http://www.abse.info

Unfortunately, like everything else new, support for it today is next to non-existent. Anyway an IDE is being built, so probably the wait is not that long...

Answer 4

If each component needs its own database, with its own set of tables (with a common prefix), and you want to eventually move all the tables from separate components into a single database for a specific project, that shouldn't be a problem. You shouldn't have hard-coded references to the name of the database in your code anyway. That should be in some kind of configuration file, with a connection string.

You'll definitely want a DAL (data access layer) for each of these sets of tables as well, to encapsulate all of the code that interacts with the database. Your application specific code (the apps that are going to reuse your login and other components) should only be interacting with your DALs -- never with the database objects directly. You should avoid using SQL directly from your application or UI code. That's what they call 3-tier or N-tier development.

Physical Database <--> DAL <--> Business Layer <--> UI code

People call those layers many different things, and some of them are often combined depending on the size and complexity of the project (for instance, I usually combine my data access and business logic layers), but the "separation of concerns" of what you're aiming for. Never jump from one layer to a non-neighboring layer (don't access the physical DB directly from your UI).

It sounds like many of your concerns boil down to general OO software design principles. The Head First series by O'Reilly are very well written books that are easy to understand and digest. I would highly recommend these two titles:

Head First Object Oriented Analysis and Design

Head First Design Patterns