I am currently working on a C# ASP.Net 3.5 website I wrote some years ago which consists of a “main” public site, and a sub-site which is our customer management application, using forms-based authentication. The sub-site is set up as a virtual folder in IIS and though it’s a subfolder of “main”, it functions as a separate web app which handles CRUD access to our customer database and is only accessible by our staff.
The main site currently includes a form for new leads to fill in, which generates an email to our sales staff so they can contact them and convince them to become customers. If that process is successful, the staff manually enter the information from the email into the database.
Not surprisingly, I now have a new requirement to feed the data from the new lead form directly into the database so staff can just check a box for instance to turn the lead into a customer.
My question therefore is how to go about doing this? Possible options I’ve thought of:
-
Move the new lead form into the customer database subsite (with authentication turned off).
-
Add database handling code to the main site. (No, not seriously considering this duplication of effort! 🙂
-
Design some mechanism (via REST?) so a webpage outside the customer database subsite can feed data into the customer database
How to organise the code for this situation, preferably with extensibility in mind, and particularly are there any options I haven’t thought of?
2
I would suggest Option #4: Create a class library encapsulating this shared functionality that both sites could add as a Reference in Visual Studio.
This new project would be a Class Library in Visual Studio. It would have Domain Models that enforce the business logic of creating a new lead, and it would have Repository classes doing the actual INSERTs, UPDATEs and DELETEs from the Database, as well as fetching the data.
While people tend to immediately gravitate towards REST services, because your two sites are both using the .NET framework a shared class library will be easier to build, deploy, and maintain over the long run. Additionally, you won’t need to incur the additional overhead of making HTTP requests and handling the responses, which will make both applications run faster for these operations.
I like to keep Martin Fowler’s advice in mind regarding Microservices (which applies to Service Oriented Architecture in general):
First Law of Distributed Object Design: “don’t distribute your objects”
Creating a REST service is just another way of “distributing your objects” since these objects must exist in both applications, and also must be serialized and deserialized for transit over a network.
He goes on to justify this “law”:
My objection to the notion of distributed objects was although you can encapsulate many things behind object boundaries, you can’t encapsulate the remote/in-process distinction. An in-process function call is fast and always succeeds (in that any exceptions are due to the application, not due to the mere fact of making the call). Remote calls, however, are orders of magnitude slower, and there’s always a chance that the call will fail due to a failure in the remote process or the connection.
(Emphasis, mine)
Why deal with a fickle network connection and web application stack when you can just make in-process calls to the same database? What you are really trying to avoid is duplicated code. Creating a shared class library for your two .NET projects achieves this.
Multiple Applications, Different Technology Stacks
If you had a public facing application written in Java, and your back-office application written in C# then you would have a good case for one of two solutions:
-
Create stored procedures in the same database that are called by both applications
-
Create a REST service called by both applications
Even then, I would go with stored procedures first, before creating a web service. If your public and back-office applications need to handle “leads” and you’ve got an Android and iOS app doing the same thing then I would create a REST or web service. Web services really start to shine in multi platform environments where one or more platforms are “client side” (i.e. in a browser, mobile app, or a third party company needs to use this functionality).
If it’s just you and your company’s web sites, go with a class library first, then stored procedures, and as a last resort create a web service.
1
I would think option 3 would be the better option. You would pass the data via a service to insert the data to your database. You should of course check what is calling your service maybe a client side cert, ip address range check, sanity check the data.
1