Software Engineering Asked by Leeish on August 3, 2020
I have a single web server running multiple web applications and websites. For simplicity we’ll just say I have App A,B,C and websites D and E. All use a shared database and some tables are used in more than one app/site.
I’m at a point where I’m looking at restructuring a lot of this code, but I’m trying to figure out a pattern that will allow me to keep as much code as possible in one spot and I’m looking for a pattern to do it.
Almost all of the apps are MVC (some legacy ones aren’t but regardless). Some App A and App B may have the same model (tied to the same table) but implemented differently with different methods and such.
I had the idea of simply building a common API that all apps/websites would use, so that the API could serve as my “model” of sorts and the apps/websites would run gets/sets through the API.
The downside I see doing that is I’d need security groups in my MVC app to control things there, AND security groups stuff in my API, which seem cumbersome. I’ve also thought about, using an API for the stuff, but in my MVC applications, making the models be abstractions of the components used for the API.
Right now I have similar functions/methods in different apps which is a headache of course, but I’m trying to make it better. Are there common models for when an app uses it’s own API and security is shared between the two?
Libraries and Services?
I don't think there is an overarching pattern that simply applies to N applications with common data. At least I don't believe there is a non-dogmatic overarching pattern.
I think you need to take a look at Refactoring in general, and specifically look at what your modularisation options are, and what makes the most sense for the particular instances of the problems you have.
Modularising common code into libraries lets you share implementations without having to rely on an available service. Done well this will allow those modules to be used in new ways. Done poorly it will make it harder to make changes that don't break every application relying on it. Take a look at plugin architecture or onion/hexagon architecture.
Wrapping the common data in a service lets you manage the validity of the data at a single point, but also creates a single point of failure that takes a lot of effort to mitigate. If you do this well it is easy to add new services, and its easy to decommission old services. If you don't do this well it becomes spaghetti code at the network level. Take a look at services/micro-services and vertical slice architecture.
Answered by Kain0_0 on August 3, 2020
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP