The Scenario
I have a Classic ASP project with a SQL Server backend that I need to port to ASP.NET MVC.
The legacy site makes liberal use of schema definition analysis in the application itself. For example, to run a given report and let the user supply a sort order, the application will read the schema and provide a list of fields based on that schema which the user can then choose (hey, NOT my design!)
This provides an interesting scenario. The migration to the new application will be done per Fowler's coined "Strangler Application" (we'll build replicated functionality piece by piece and slowly move it over). However, along with this are some requirements for new functionality, which will mean new fields and new tables. Due to this, I'm hesitant to just go throwing new fields in existing tables, because I don't want to screw up anything in the legacy app. Naturally, due to the migration path, we need to be able to use both systems at once for a time.
Additionally, the legacy app's database naming is quite horrid, including any number of reserved words and special characters and so on. Also, some table names are completely non-semantic (for example, their primary "Members" table is in fact named after their first and primary client from some 20 years ago).
My Thoughts
So, we have one database, let's call it LegacyDB
This cannot change. Yet we need to add new functionality for the new site. My thought was to create a second database, call it NewDB
. This will contain any/all "new" data. I'd maintain a pseudo-1:1 relationship between the tables in LegacyDB
and 'NewDB' on each table's ID.
What I'd then like to do is build some sort of abstraction database over both of them that the new application will interact with. This would receive a query like SELECT blah FROM dbo.Members WHERE blah = blah
, and would query from both the LegacyDB
and any new fields as required from the NewDB
. Likewise, all other CRUD operations against the "abstraction" db or "facade" db (for lack of a better term) would similarly work the same. I'm thinking some carefully crafted views could be used to manage this.
This way the existing legacy app could use the LegacyDB
without having to do any major reworks to that mess, and the new application would have a nicely-named and new-feature-enabled database to work with without having to manage replications between two separate databases.
Once the legacy app is fully phased out, the LegacyDB
and NewDB
would be merged and theoretically take place of the abstraction/facade db without requiring application level changes.
Essentially what I'm thinking is top-level views in the facade db that would in turn pull data from the appropriate databases. If the application sends the following query to the facade:
SELECT Field1, Field2, Field3 FROM ThisTable
The facade would have ThisTable
defined as a view:
CREATE VIEW ThisTable AS (
SELECT
a.LegacyField1 AS Field1,
a.LegacyField2 AS Field2,
b.NewField3 AS Field3
FROM legacyDb.dbo.BadTableName AS a
INNER JOIN newDb.dbo.GoodTableName AS b ON a.ID = b.ID
);
(for updates, I haven't quite worked out the feasibility - one of the reasons I'm asking here)
My Questions
Is this a crackbrained idea? Has anyone tried it? Is there a common name for this approach (if it's even a common approach). Is there some reference I can find for pros/cons/gotchyas? I'd be quite grateful for some experience to feed off of before I start the undertaking.