LessThanDot Site Logo

LessThanDot

A Technical Community for IT Professionals

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Highly Rated Users

Forum
No Posts Rated

Top 50
Given
Received

Links

Wiki
Blog

Forum Statistics

Users
Members:
1884
Members Online:
2
Guests Online:
95

Total Post History
Posts:
81461
Topics:
18719

7-Day Post History
New Posts:
4
New Topics:
1
Active Topics:
2

Our newest member
manails232x

Other

FAQ
All times are UTC [ DST ]

Developing a Multi-Application Solution

Building Solutions, Composition of Applications, etc
Please wait...

Developing a Multi-Application Solution

Postby deepoos on Thu Jan 22, 2015 12:43 am

My first post, if any mistakes please ignore.

I am looking for some assistance in designing a single solution which houses different applications. Backgroud: There are about 10 applications built on microsoft technologies over a period of time using classic ASP to .net 4.0. We are growing rapidly and maintaining these app's and enhancements is becoming a nightmare. We have added lots of patch work to satisfy needs. There is only one database for all these applications.
We want to create a solution to house a single solution which houses only business functions of these applications. Can anyone point me right direction in reaching this goal?
deepoos
Newbie
Newbie
 
Posts: 3
Joined: Thu Jan 22, 2015 12:32 am
Unrated

Re: Developing a Multi-Application Solution

Postby Kermit on Mon Jan 26, 2015 4:27 pm

Hi deepoos what you have described is a wishlist for most product managers and sometimes a nightmare for many development teams!

I see several things here:

1. You need to maintain the legacy applications?

If you do then you will want to look into using a service bus of some kind made up of Web Services and/or WCF to allow communication between the legacy apps and your new framework as well as future applications.

2. Technology

What technology are you looking to use? are you limited to certain technologies due to Infrastructure rules and/or budget reasons or other?

3. Why a single database? To share data?

I would recommend a database per application domain at least or better per application and then use your service layer to share the data and work with it through a common data interface (I will explain in a minute).

--- My Solution:

Lets assume you are sticking to the Microsoft stack and are not limited or technology shy then I would use C# with the .NET 4.5 Framework coupled with MVC 4 & 5 and WPF applications, where required employ Web Services written in C# or if you have to time to learn the technology in WCF and specifically taking advantage of WebAPI if all your apps will be web based.

WPF will allow you to interface with your new applications and provide a rich interface that is not completely desktop bound.

I would use Web Services because they work better with older technology and you may need to do some integration work at various levels (Database, Application and Infrastructure) this means getting data from one system into a format that works in another independent of your code.

Finally the framework. In nutshell I would use C#, .NET 4.5, Good separation of concerns via a sandwich stack (if you don't know what this means take a look at some architecture diagrams they appear to look like sandwiches hence the name) - the principle here being that your data layer sits at the bottom and your UI layer at the top while the business and application layer sits in the middle with interfaces that talk to the legacy applications.

Use the Repository pattern for you data layer, it takes care of the CRUD operations and provides good separation between code logic and the underlying database meaning you can switch your database in the future and the impact is very little in terms of your framework.

Your application layer interacts with the data layer but the data layer has no concept of the application layer - this is for security.

And subsequently the business layer interacts with the application layer but the application layer has no (vertical) concept of the business layer above it however does have interfaces and endpoints (horizontal) that allow interaction with the external legacy and 3rd party systems via it's own API or other API's.

The business layer sits under the UI layer but is separate to the UI layer allowing for things like test driven development, mocking etc without reliance on the User Interface code or being tightly coupled (which you don't want).

The business layer would typically consist of Interfaces and Classes local to the application at that level e.g. one scenario would be an MVC application that has controllers, models, View Models, Views and any custom classes.

Between the Business layer and the Application layer sits the intermediate layer which is essentially all your helper classes, worker classes, utilities etc moved to this layer away from cluttering your main code.

Skinny Implementation, Fat classes

This means keep your implementation light and lean so your UI and business code is easy to ready and maintain and as you go through the layers you start to get fat classes with the largest sitting deep down in the lower layers from the intermediate layer down.

The intermediate layer(s) exist to ensure you do not touch the low level base layers (application and beyond) as you are breaking some fundamental maintainability rules if you do and the idea of the intermediate layer is to wrap up code and act as a bridge.

The above is the basics of a solid usable framework that works across almost all app types but you need to visualize it so I have tried to give you an ascii version below:

[--- USER INTERFACE > WebForm/WinForm/WPF/MVC/Console/Custom ---]

[--- USER INTERFACE FRAMEWORK: Bootstrap/AngularJS etc ---]

[--- BUSINESS LAYER: Business Logic i.e. actions on the UI ---]

[--- HIGH LEVEL ENTITIES ---]

[--- INTERMEDIATE LAYER ---] ------------------> (WS) <-----> External/Legacy

|
|
\/

[--- APPLICATION LAYER: Classes that interact with the Repository
acting on a given entity e.g. "CUSTOMER" ---]

[--- ENTITIES: DB Mapped Entities ---]

[--- REPOSITORIES ---]

[--- DATA LAYER: Models, DTO's, Queries etc ---]


*** With the above it is assumed you would be using Entity Framework 6.1 (the latest version is great and finally a capable solution for ORM etc) however anything like nHibernate could be used).

Obvious stuff like if you want things to be reusable for example you have a common object like Customer then create a base abstract class that can be used to create other classes and then create interfaces that add additional features when a class subscribes to it.

It all depends on what you want to achieve but for simplicity and maintainability I would go for the above because it's light and the architecture can be expanded further.

If you want to see something in code form take a look at this project on github:

https://github.com/devbridge/BetterCMS

Better CMS is a very well built Content Management System however their back end framework is very similar to what I cooked up at home so would be a good starting point.

If you don't understand any of the above then I advise you go away and learn the concepts until you do otherwise you will have a mountain to climb, any experienced developer will be able to understand my ramblings above.

Finally I hope my colleagues on this forum will also add their more experienced views here as I probably missed a load of things.

Adios.

T
MotherFbleeper
User avatar
Kermit
LTD Admin
LTD Admin
LTD Bronze - Rating: 125LTD Bronze - Rating: 125LTD Bronze - Rating: 125
 
Posts: 571
Joined: Thu Oct 11, 2007 11:14 am
Location: United Kingdom

Re: Developing a Multi-Application Solution

Postby deepoos on Tue Jan 27, 2015 12:56 am

Thank you Kermit for a very detailed response. I can totally understand the level of involvement in developing a single solution to reflect what has done until now under one umbrella.

But I am having difficulty in making management understand the scope and level of effort this kind project would take. Any ideas to ask for more time would help.

Thanks,
D
deepoos
Newbie
Newbie
 
Posts: 3
Joined: Thu Jan 22, 2015 12:32 am
Unrated

Re: Developing a Multi-Application Solution

Postby Kermit on Thu Jan 29, 2015 11:02 pm

I can understand and appreciate the challenge you are facing with management and unfortunately it's the same almost everywhere.

What you need to do is talk in terms of numbers and effort and quantify this in some way like a graph over a period that allows them to visualise how the cost will be spread and ultimately who to charge (or recharge).

Breakdown the whole thing into smaller manageable projects for example we know from the earlier discussion that some kind of foundation architecture is required with a basic framework on top of this (could be something as simple as a bunch of libraries to unify common operations and tasks like working with data to more complex services and interactions).

You can pitch this on the basis that it will be an immediate improvement and you could provide something measurable like performance and say that X % performance will be gained and Y % issues will be reduced.

Keep it simple and start with the lowest layer so you can quickly start to integrate and essentially integration test the solution as it evolves a piece at a time e.g. starting with the Data Access layer, then the Application layer, Service layer(s), Security and so on.

Common reusable generic modules, components, entities and objects that are accessible via localised services or just some basic interfacing done through one or more libraries.

You can then start to build on top of this, making use of the features that you have created and continue to evolve or add whilst still focusing on getting new projects moving along such as enhancing an existing application to make use of "THIS" new architecture.

Split the work up into manageable chunks assessing the milestones as you go along applying a "COMPLEXITY vs EFFORT vs COST" formula and be brutally honest here if something is going to take 60 days then say 60 days.

This will allow you to further divide up the work into chunks and then later into units of work that allow you to be agile in your approach and development whilst reducing risk and fallout (meaning if a small unit of work becomes complex or is affected by loss of resources or has a bunch of issues at release time the impact will be contained and easy to deal with as it's a unit of measured and recorded work).

You can then workout how many resources will be required for the chunks of work:

- Do you pair up developers over 2/4/8 weeks?
- Lone developers that work on individual chunks of work and/or units of work spanning 1 to 5 days?
- Round robin the work assigning chunks (and sometimes smaller units) of work as and when you find the time between your other work that generates money for the company?

You need to be able to present the work in a manner that allows project managers and upper management to be able to forecast the work involved, effort and ultimately costs which could mean you do a large chunk in the first quarter of the year and then bits throughout before you do a large piece of work again near the end of the year (this is the reality).

Think of your solution as an ecosystem you grow from the inside out so don't aim too big and too bold - you will never get it done and no one will sign-off the project however if you keep things small and easy to deliver and manage you can always argue the merit of any costs and effort for efficiency of delivery and low bugs.

Keep things common and relevant - use technology that is widely available, easy to implement and well supported by the community and avoid trying to engineer stuff unless you really have to as most of your effort should be focusing on integration development (getting stuff to talk to each other without too much complexity).

Software delivery is about being functional (user specific), maintainable, on time & under budget...mostly and the only way you will achieve this is if you use techniques, tools, patterns & practices that work and are bullet proof and thankfully the development and product market is rich with resources now.

Initial quick delivery will earn you merit and allow you to get buy-in from others which means you may get more time and resources in the future. Trying to deliver one big bang is a recipe for disaster as your end goal will always keep moving and when you do deliver something it will be a big pile of cluttered crap.

There is more and my colleagues and others on LTD will be able to provide you with more answers and information.

It's a challenge but that's what we thrive on!
MotherFbleeper
User avatar
Kermit
LTD Admin
LTD Admin
LTD Bronze - Rating: 125LTD Bronze - Rating: 125LTD Bronze - Rating: 125
 
Posts: 571
Joined: Thu Oct 11, 2007 11:14 am
Location: United Kingdom

Re: Developing a Multi-Application Solution

Postby AlexCuse on Fri Jan 30, 2015 1:02 am

Another option might be to start moving shared functionality into a core library. Deployments get tricky but you could register it as a COM component and call it from your classic ASP sites, or reference it directly in your more modern apps.

This is clearly not where you would go on a greenfield project but if you can't justify the time / cost involved with building a complete service layer this type of approach can at least get your shared business logic defined in a single place and ease your pain going forward. It would also make it easier to update the older applications when you can find the time.
Say what you like about the tenets of National Socialism Dude, at least it's an ethos
User avatar
AlexCuse
LTD Admin
LTD Admin
LTD Gold - Rating: 1031LTD Gold - Rating: 1031LTD Gold - Rating: 1031LTD Gold - Rating: 1031LTD Gold - Rating: 1031
LTD Gold - Rating: 1031LTD Gold - Rating: 1031LTD Gold - Rating: 1031LTD Gold - Rating: 1031LTD Gold - Rating: 1031
LTD Gold - Rating: 1031
 
Posts: 5524
Joined: Tue Oct 09, 2007 5:26 pm
Location: Pennsylvania, US

Re: Developing a Multi-Application Solution

Postby Kermit on Sat Jan 31, 2015 2:19 am

Yes good addition Alex, I had forgotten the legacy aspect and that would be one of many good solutions and act as a bridge in the future if you ever do decide to and manage to upgrade those apps.
MotherFbleeper
User avatar
Kermit
LTD Admin
LTD Admin
LTD Bronze - Rating: 125LTD Bronze - Rating: 125LTD Bronze - Rating: 125
 
Posts: 571
Joined: Thu Oct 11, 2007 11:14 am
Location: United Kingdom
Unrated

Re: Developing a Multi-Application Solution

Postby deepoos on Mon Feb 09, 2015 7:01 pm

Thanks again Kermit for a very detailed response. And Alex for suggesting COM support.
deepoos
Newbie
Newbie
 
Posts: 3
Joined: Thu Jan 22, 2015 12:32 am
Unrated

Re: Developing a Multi-Application Solution

Postby Lana3 on Wed Dec 21, 2016 4:26 pm

Wow. It's a good job guys.
Life is beautiful :)
Lana3
Newbie
Newbie
LTD Bronze - Rating: 1
 
Posts: 3
Joined: Wed Dec 21, 2016 4:22 pm
Unrated