8 Replies - 1023 Views - Last Post: 27 February 2019 - 08:40 AM

#1 fearfulsc2   User is offline

  • D.I.C Head

Reputation: 15
  • View blog
  • Posts: 243
  • Joined: 25-May 16

Decouple/Transform very tightly coupled monolithic application

Post icon  Posted 21 February 2019 - 08:06 AM

Hi everyone, I have an application that runs on .NET MVC and it has 12 layers of dependency such as many other class library projects that were written to do many other things. The previous developers used this "framework" for other applications but built on top of it all.

The MVC application is the most modern of their applications and does not use any APIs.

What I wanted to know is how should I tackle this if I wanted to use Angular5/6/7 and create an API for the MVC application?

Would I create the front-end first to mirror what it looks like today and then create an API to start?

How do you normally decouple applications?

Is This A Good Question/Topic? 3
  • +

Replies To: Decouple/Transform very tightly coupled monolithic application

#2 andrewsw   User is offline

  • Stealth IT
  • member icon

Reputation: 6736
  • View blog
  • Posts: 27,734
  • Joined: 12-December 12

Re: Decouple/Transform very tightly coupled monolithic application

Posted 21 February 2019 - 08:31 AM

Personally, I would work back to front. Database > Models/ORM > API (test this)
> Angular service > basic component to test the service

The front-end is pretty pictures.

I would consider

How much can you keep or salvage from the solution
Is it worth the effort? The cost?
Who is meeting the costs?
Do you really need Angular

I would start with a completely new solution/projects (having resolved the above questions).
Was This Post Helpful? 0
  • +
  • -

#3 fearfulsc2   User is offline

  • D.I.C Head

Reputation: 15
  • View blog
  • Posts: 243
  • Joined: 25-May 16

Re: Decouple/Transform very tightly coupled monolithic application

Posted 21 February 2019 - 08:49 AM

That's a good approach. The back-end is a little scary since they created their own little version of "Entity Framework"

They created their own way to generate an xml mapping of the database and created their own dbMapper framework

for example
public class TableDbMapper<T> : ServerDbMapper<t> where T : class, new()
{
 // does stuff
}

public class ServerDbmapper<T> Project.Data.SqlDb.DbMapper where T : class, new()
{
 // does stuff
}

public abstract class DbMapper : Data.DbMapper
{
 // does stuff
}

// finally
public abstract class DbMapper
{
 // does stuff
 // in here has all the generic stuff such as mapping column to field names, etc.... update, delete, add, select, etc....
}



I wanted to implement entity framework but could not figure out where to add it into this project which is why I wanted to start off with the front-end and work toward the back.

I know with Entity Framework, the xml mapping is automatically generated for me.
Was This Post Helpful? 0
  • +
  • -

#4 andrewsw   User is offline

  • Stealth IT
  • member icon

Reputation: 6736
  • View blog
  • Posts: 27,734
  • Joined: 12-December 12

Re: Decouple/Transform very tightly coupled monolithic application

Posted 21 February 2019 - 09:14 AM

If there is already this ORM, hopefully as a distinct project, and it works well, then I'd probably stick with it.

Again, it depends on whether it is suitable for the job, now and going forward, and how much time and effort can be given to replacing it.

off-topic
We have a very heavily architect-ed application, with a generic repository (integrators, integrations, T4 templates, etc.). It is a real pain to trace through and try and work out what is going on.
Was This Post Helpful? 0
  • +
  • -

#5 fearfulsc2   User is offline

  • D.I.C Head

Reputation: 15
  • View blog
  • Posts: 243
  • Joined: 25-May 16

Re: Decouple/Transform very tightly coupled monolithic application

Posted 21 February 2019 - 10:03 AM

The ORM is not as a distinct project but spans across 2 or 3 project as class libraries and they inherit from one base DbMapper class.

Whenever a new column is added or removed from the database, I have to use their own sql stored procedure to regenerate the xml mapping and then add that property to one of the classes(which they also create from a stored procedure if I wanted to go that route. [Yes, the stored proc can generate a c# class which I thought was interesting.])

The only issue I am dealing with is that it takes a lot of work to make medium/big changes and you have to have a strong knowledge of how their code works in order to make changes successfully. It is very hard to hand this code to another developer and have them figure it out on their own. It is not maintainable in that regard. Short-term this project I am thinking about won't be of much benefit. But long-term, it would be a huge benefit to do since I know one day someone else will work on this and they may have an extremely hard time trying to work through it.
Was This Post Helpful? 0
  • +
  • -

#6 Skydiver   User is online

  • Code herder
  • member icon

Reputation: 6763
  • View blog
  • Posts: 23,066
  • Joined: 05-May 12

Re: Decouple/Transform very tightly coupled monolithic application

Posted 22 February 2019 - 08:13 AM

I love this pattern: "Strangler Pattern" identified/introduced by Martin Fowler.

The Strangler pattern in practice by Michiel Rook.
Was This Post Helpful? 4
  • +
  • -

#7 baavgai   User is offline

  • Dreaming Coder
  • member icon


Reputation: 7397
  • View blog
  • Posts: 15,330
  • Joined: 16-October 07

Re: Decouple/Transform very tightly coupled monolithic application

Posted 22 February 2019 - 08:17 AM

My first step in any application is an interface.
public interface IRepo {
    IEnumerable<Models.Customer> GetCustomers();



This not only helps you know where to start, for an existing system, it gives you a non breaking way to describe what's already there. With this, you can immediately start getting a handle on the chaos you've inherited. Indeed, describing interfaces for all the public moving parts can help a lot.

In new system, the next step might look like:
public class Repo : IRepo {
    private readonly AppDbContext dbCtx;
    public Repo(AppDbContext dbCtx) { this.lwaContext = lwaContext; }
    public IEnumerable<Models.Customer> GetCustomers() => dbCtx.Customers;



Again, this can help immensely in wrangling a legacy system, as you have something like HorribleOldClass : IWhatItDo and ShinyNewClass : IWhatItDo. You can even do this side by side with something like:
public class Thingy : IThingy {
    private readonly IThingy legacyThingy;
    private readonly IThingy cleanedThingy;
    public State IThingy.DoThing1() => legacyThingy.DoThing1();
    public State IThingy.DoThing2() => cleanedThingy.DoThing2();



In a modern .NET Core system the final stop is injection into a web API controller. However, even in an ancient .NET design, this kind of thing is still applicable.

Hope this helps.
Was This Post Helpful? 2
  • +
  • -

#8 fearfulsc2   User is offline

  • D.I.C Head

Reputation: 15
  • View blog
  • Posts: 243
  • Joined: 25-May 16

Re: Decouple/Transform very tightly coupled monolithic application

Posted 22 February 2019 - 08:21 AM

Thank you for the insight!

Also the Strangler pattern is interesting.

I was thinking of adding interfaces since I can use dependency injection more effectively in my opinion as well as being able to switch out different libraries if need be.

For example, one of the libraries being used is not an approved library for us to use, so I have to switch that library out with another library and hope that nothing breaks. In that case, I will have to do a lot of work to switch them all out but I think with an interface, I might be able to cut that rework down a bit.
Was This Post Helpful? 0
  • +
  • -

#9 jon.kiparsky   User is online

  • Beginner
  • member icon


Reputation: 11423
  • View blog
  • Posts: 19,473
  • Joined: 19-March 11

Re: Decouple/Transform very tightly coupled monolithic application

Posted 27 February 2019 - 08:40 AM

The Strangler is a nice pattern, but you should probably pick up a copy of Michael Feathers' book on "Working With Legacy Code". Deep insights into exactly this problem. Also, there is a book out there on "refactoring to patterns" which might be interesting for you. The latter is basically "practical refactoring". The two books together should give you plenty of ideas to play with.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1