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).
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
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)
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.