How should I architect a .NET "Interface" to accommodate database requests + database responses?
My team is building a new ASP website. I'm primarily a VB/C# developer (very little ASP) but have a full-time web-developer on the team. Our first milestone with this project will be a simple demo for stakeholders.
Simple enough, but here's the sticky part: the primary SQL Server database (and its in-house server) is being dramatically changed at the moment-- impacting multiple teams. That's out of our hands and we won't know what the database will eventually look like, nor where it will reside, until after the demo. So we're creating the demo without answers to these questions anyway. And that's where I come in. I've been tasked with creating some kind of interface (with an actual .net interface or a pseudo one) to permanently stand-in for the database. I thought we can make lemon-aid out of lemons and make this interface permanent. It will serve up "made-up" data for the demo now, and be programmed to talk to the primary database later. That way the web-site will just continue making requests of this interface the same way it does in the demo and not have to be re-coded.
I'm not sure what I'll use to create this interface however (ASP I expect...and that's ok) nor what the architecture will look like (internal web-service?, a PowerShell class that contrives the "made-up" demo data now and later is implemented by the primary database?). (I'm not sure if a SQL Server database can formally implement a .NET interface, can it?).
In essence, the site will request (from the interface) that such-and-such data be retrieved for such-and-such customer, and the interface will worry about performing that action and returning the results. It will put together the sql queries and worry about which source(s) to pull from.
Can you guys help me get started?
Simple enough, but here's the sticky part: the primary SQL Server database (and its in-house server) is being dramatically changed at the moment-- impacting multiple teams. That's out of our hands and we won't know what the database will eventually look like, nor where it will reside, until after the demo. So we're creating the demo without answers to these questions anyway. And that's where I come in. I've been tasked with creating some kind of interface (with an actual .net interface or a pseudo one) to permanently stand-in for the database. I thought we can make lemon-aid out of lemons and make this interface permanent. It will serve up "made-up" data for the demo now, and be programmed to talk to the primary database later. That way the web-site will just continue making requests of this interface the same way it does in the demo and not have to be re-coded.
I'm not sure what I'll use to create this interface however (ASP I expect...and that's ok) nor what the architecture will look like (internal web-service?, a PowerShell class that contrives the "made-up" demo data now and later is implemented by the primary database?). (I'm not sure if a SQL Server database can formally implement a .NET interface, can it?).
In essence, the site will request (from the interface) that such-and-such data be retrieved for such-and-such customer, and the interface will worry about performing that action and returning the results. It will put together the sql queries and worry about which source(s) to pull from.
Can you guys help me get started?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Side-note (ignore if you want)...
Have you used PowerShell? For some reason I want to use PowerShell as a solution...not sure why (I'm not a PowerShell guy).
Have you used PowerShell? For some reason I want to use PowerShell as a solution...not sure why (I'm not a PowerShell guy).
The Repository pattern can be done entirely in C# / VB. The Controller (if you're using one) is oblivious to the Repository. The Repository site between the data source layer and the model.
The abstraction with Web API is divided between client side and server side. Server side code provides the "endpoints" that can be accessed from the client side using AJAX.
So, in your case, I think the Repository pattern would be a better choice. It's at a deeper level.
I've never used PowerShell.
The abstraction with Web API is divided between client side and server side. Server side code provides the "endpoints" that can be accessed from the client side using AJAX.
So, in your case, I think the Repository pattern would be a better choice. It's at a deeper level.
I've never used PowerShell.
ASKER
So I could write a Repository (and a Controller) in C#/VB and use this architecture? For the Demo I guess the DB and Framework are removed and the fake-data is placed directly in the repository...correct?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Great advice. Thanks!
ASKER
I read the link you provided (and I'm familiar with design patters - decorator, fly-wheel, observer, etc...not that one though). That's a great start, it may be just the thing.
So, the database may end-up being behind a firewall that I'll need to tunnel to (yet to be seen though). Or it could end-up being a copy of the primary database that lives in the DMZ. Would either of these points persuade you one way or another (API vs. Repository pattern)?
Also, if I can build this in C# or VB that would be even better.