- Databases
- .NET Programming
- C#
Application Architecture Planning
Happy Holidays All!
I'm looking for some advice on best practices for modern application architecture.
Background:
We have a custom ERP software that was written (and still being used) in about twenty Access 2003 databases. Each module covers some functionality of the business with minor linking in between.
The good news is we're finally ready to start building new applications, and, going to be replacing these legacy modules as time allows. In addition the database schema is somewhat of a mess that I also intend on cleaning up eventually.
Current setup:
These VMs are running on VMware with HA configured (2 physical hosts, properly provisioned)
SQL server VM
a RDP / File Server / Application server VM
2 AD servers (one per host, non-HA)
My partner has recommended going with a 3 tier architecture to allow for flexibility and uniformity, with specifically a WCF middle-tier to allow for binary communication in-house and an http endpoint for any extranet needs. That would go on the application server.
Desktop apps would then be deployed to each user computer as necessary. (We have a current update batch file which users are used to running to pull down new code bases, all applications run locally). The applications would then pull from the WCF middle tier and access the data that way.
Is 3 tier still the best approach? Also in terms of the desktop apps would you recommend UWP or Windows Forms? Is EF still the preferred ORM?
Users have Windows 10 desktops. We don't have any real need for the extranet yet but it's on the list wish for the executive board (EG: They want an app that our reps can use on their mobile devices).
Any thoughts or advice on the high level layouts would be greatly appreciated. Looking for lessons learned and what kind of traps I should be looking out for.
Thanks in advanced.
I'm looking for some advice on best practices for modern application architecture.
Background:
We have a custom ERP software that was written (and still being used) in about twenty Access 2003 databases. Each module covers some functionality of the business with minor linking in between.
The good news is we're finally ready to start building new applications, and, going to be replacing these legacy modules as time allows. In addition the database schema is somewhat of a mess that I also intend on cleaning up eventually.
Current setup:
These VMs are running on VMware with HA configured (2 physical hosts, properly provisioned)
SQL server VM
a RDP / File Server / Application server VM
2 AD servers (one per host, non-HA)
My partner has recommended going with a 3 tier architecture to allow for flexibility and uniformity, with specifically a WCF middle-tier to allow for binary communication in-house and an http endpoint for any extranet needs. That would go on the application server.
Desktop apps would then be deployed to each user computer as necessary. (We have a current update batch file which users are used to running to pull down new code bases, all applications run locally). The applications would then pull from the WCF middle tier and access the data that way.
Is 3 tier still the best approach? Also in terms of the desktop apps would you recommend UWP or Windows Forms? Is EF still the preferred ORM?
Users have Windows 10 desktops. We don't have any real need for the extranet yet but it's on the list wish for the executive board (EG: They want an app that our reps can use on their mobile devices).
Any thoughts or advice on the high level layouts would be greatly appreciated. Looking for lessons learned and what kind of traps I should be looking out for.
Thanks in advanced.
These days, why wouldn't you consider a web based UI? Fat clients are pretty much a thing of the past for shared applications and much harder to maintain.
I still prefer 3-tier that separates the UI from the database with the middle tier which can be simple web services.
I still prefer 3-tier that separates the UI from the database with the middle tier which can be simple web services.
Hi,
First of all, 3 tier means 3 physical layers. It refers to the deployment of the app, not to the software architecture. So, you’re referring to 3 layers. This architectural approach is fine if you have a monolith app. That means, specifically, a single deployment unit and a single (conceptual) data storage. Traditionally, these apps are data-centri, the database is the master.
To overcome the disadvantages of the inherently tight coupling between layers, the clean architecture has appeared, based on domain-driven design concepts, hexagonal architecture and some other good principles and practices.
First of all, 3 tier means 3 physical layers. It refers to the deployment of the app, not to the software architecture. So, you’re referring to 3 layers. This architectural approach is fine if you have a monolith app. That means, specifically, a single deployment unit and a single (conceptual) data storage. Traditionally, these apps are data-centri, the database is the master.
To overcome the disadvantages of the inherently tight coupling between layers, the clean architecture has appeared, based on domain-driven design concepts, hexagonal architecture and some other good principles and practices.
I think that the concept of N-Tier is always relative..either in "physical" form or "virtual " (as a concept)
The things are simple if you can picture this.
1st You need a database ...that's the most critical part...a good designed Database with an "eye for the future" means that you have a solid ground for everything else..(keep in mind that even World Class ERPs are relying on very old implementations from 80s,90s)
2nd the data layer...it can be as fancy as you want...ORM or not ORM ...the essential part is to get the data pulled as quickly as possible...i am not sure about the ORM concept unless is pretty dynamic (haven't dealt with such implementation)...but i really don't like the idea of recompiling an ERP class application because you just added a field to a table .... i always try to use a Table Oriented Programming culture...whatever you can represent/store in a table just do it in a table...don't mess with classes and code
3rd The Business Layer...this is a rather complex case....it supposed to hold all the logic of the application ....the most important part is that it has to be resilient to both "Input" and "Output"....and of course to provide a helping hand against all other layers
4th The Presentation Layer...well here is where everything boils down... here a key concept is that all the previous layers would/should work for this and by this...as @Eduard mentioned...you need to make sure that you are not "locked" to a design that will "lock" the application to a single UI...todays is WinForms or WPF ...tomorrow is Web...in a few years it could be a mobile/tablet....usually the idea is that this Layer is broken in 2...a Layer that acts pretty much as the Business Layer but holding only the "logic" of the UI and the actual UI...
I must add that your post was somewhat a blast of the past....till few years ago ..i was working on a similar case...many many modules forming a gigantic Ms Access 2003 MRP/ERP ....still is the same after all this time to my knowledge
The things are simple if you can picture this.
1st You need a database ...that's the most critical part...a good designed Database with an "eye for the future" means that you have a solid ground for everything else..(keep in mind that even World Class ERPs are relying on very old implementations from 80s,90s)
2nd the data layer...it can be as fancy as you want...ORM or not ORM ...the essential part is to get the data pulled as quickly as possible...i am not sure about the ORM concept unless is pretty dynamic (haven't dealt with such implementation)...but i really don't like the idea of recompiling an ERP class application because you just added a field to a table .... i always try to use a Table Oriented Programming culture...whatever you can represent/store in a table just do it in a table...don't mess with classes and code
3rd The Business Layer...this is a rather complex case....it supposed to hold all the logic of the application ....the most important part is that it has to be resilient to both "Input" and "Output"....and of course to provide a helping hand against all other layers
4th The Presentation Layer...well here is where everything boils down... here a key concept is that all the previous layers would/should work for this and by this...as @Eduard mentioned...you need to make sure that you are not "locked" to a design that will "lock" the application to a single UI...todays is WinForms or WPF ...tomorrow is Web...in a few years it could be a mobile/tablet....usually the idea is that this Layer is broken in 2...a Layer that acts pretty much as the Business Layer but holding only the "logic" of the UI and the actual UI...
I must add that your post was somewhat a blast of the past....till few years ago ..i was working on a similar case...many many modules forming a gigantic Ms Access 2003 MRP/ERP ....still is the same after all this time to my knowledge
why wouldn't you consider a web based UI
You lose all of the processing power of the individual PCs as well as having to worry about the state of any given page. It's possible that we expose some things using web interfaces, but that'd be limited in scope.
I think that the concept of N-Tier is always relative..either in "physical" form or "virtual " (as a concept)
I completely agree with this. The physical deployment is a different topic entirely. You could, in theory, but the DB, data layer, and business layer on one box (not that you would, but you could). The whole point of coding the layers separately is so that they can be deployed independently and scale as needed.
To that end, I'm wondering if it's better to deploy the DAL on each client and distribute the load. Or is it better to bottleneck on the app server?
The "books" say that the app server should handle all the load...i don't think it as the load...but ..
Lets take a look at your current status...you have multiple modules that do a lot of different jobs...if you are extremely "dedicated" your code would be clear and probably you have grouped similar concepts to "in between" modules but ....there are always cases that this is not possible...
Wouldn't be just "great" to have everything handled and controlled in HQ ...a central point where one change affects immediately everyone...so you only do the job once and you know that job is done.
As for the concept of processing power and layers/tier...just start building and you will see what is needed and what is not.
At first at least separate the database engine from all the rest....1 server for MSSQL/MySQL (or what ever) ...1 server for DAL/BLL
Finally ....today you have powerful workstations...in a few years "probably" your work is shifted on phones/tablets ... OR thin clients..so don't assume that you will have scattered processing power...just try to be "flexible"
Lets take a look at your current status...you have multiple modules that do a lot of different jobs...if you are extremely "dedicated" your code would be clear and probably you have grouped similar concepts to "in between" modules but ....there are always cases that this is not possible...
Wouldn't be just "great" to have everything handled and controlled in HQ ...a central point where one change affects immediately everyone...so you only do the job once and you know that job is done.
As for the concept of processing power and layers/tier...just start building and you will see what is needed and what is not.
At first at least separate the database engine from all the rest....1 server for MSSQL/MySQL (or what ever) ...1 server for DAL/BLL
Finally ....today you have powerful workstations...in a few years "probably" your work is shifted on phones/tablets ... OR thin clients..so don't assume that you will have scattered processing power...just try to be "flexible"
>>You lose all of the processing power of the individual PCs
What type of PCs did you buy them all? Most PCs aren't set up to handle that much processing. A single app server should be able to handle the workload of many PCs and not break a sweat.
I'm not recommending this but on Intranet apps I've seen large Javascript files that make a pretty robust website. That can offload a lot of processing to the client. Only downside is the initial download and caching of the Javascript files.
>>as well as having to worry about the state of any given page
I don't see the issue. If done right, things should be more or less stateless but I don't know all the ins and outs of ERP and what processing you are doing.
What type of PCs did you buy them all? Most PCs aren't set up to handle that much processing. A single app server should be able to handle the workload of many PCs and not break a sweat.
I'm not recommending this but on Intranet apps I've seen large Javascript files that make a pretty robust website. That can offload a lot of processing to the client. Only downside is the initial download and caching of the Javascript files.
>>as well as having to worry about the state of any given page
I don't see the issue. If done right, things should be more or less stateless but I don't know all the ins and outs of ERP and what processing you are doing.
Hi,
As I see, the suggestion are following the same old school of thoughts: database is the most important. You’ll need some sort of storage, but don’t focus on that. Database is a detail, it shouldn’t be the main concern. What you’ll need to focus on is the Domain, what entities do you have, what are the interactions between them, what are the business rules, in a word, the MODEL. Don’t fall into the trap of thinking in Database terms: this is going to affect your app In negative way on medium and long term.
As I see, the suggestion are following the same old school of thoughts: database is the most important. You’ll need some sort of storage, but don’t focus on that. Database is a detail, it shouldn’t be the main concern. What you’ll need to focus on is the Domain, what entities do you have, what are the interactions between them, what are the business rules, in a word, the MODEL. Don’t fall into the trap of thinking in Database terms: this is going to affect your app In negative way on medium and long term.
@Edward ... interesting thoughts on the subject...do you have some kind of material to back them up...or they are just your opinion.
Hi,
There are my thoughts based on experienced and on what other architects are sharing as common understanding about Clean Architecture. You can start by having a look at: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
There are my thoughts based on experienced and on what other architects are sharing as common understanding about Clean Architecture. You can start by having a look at: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Well @Edward the presence of "Uncle Bob" surely is not something to ignore...but I must argue on the concept how much weight a detail should carry...in other words a detail usually has a meaning of "trivial".
And now comes the question..Bob considers the DB a detail given the fact that someone else has done a tremendous job providing a database design that "liberates" the programmer from the concern of data in their raw state or detail means...just ignore design..just make tables that follow a free form of IO like Excel...if the 2nd is the case I would like to see a concrete application based on that philosophy.
And now comes the question..Bob considers the DB a detail given the fact that someone else has done a tremendous job providing a database design that "liberates" the programmer from the concern of data in their raw state or detail means...just ignore design..just make tables that follow a free form of IO like Excel...if the 2nd is the case I would like to see a concrete application based on that philosophy.
Hi,
In the end, it's all about trade-offs. Let's follow your approach and analyze it.
Database - A big design on the database side means, almost in all cases, to have business rules implemented at that level. Also, the specific ways of representing the data will influence the overall design.
Data layer - If the database is the main pillar, it will influence the design of the entities, regardless if an ORM framework will be used or not. It will be heavily dependent on the database design and will propagate this dependency to the above layer instead of hiding it. It is going to become even worst if Entity Framework is used because the so-called entities will be just a projection of the database structure.
Business layer - As long as the main logic is in the database, there is almost no need for it. This layer will be, usually, pretty thin, and will contain logic to act upon the EF entities from the data layer, so the storage details will pop-up to this layer.
The Presentation layer - will be required to know about the EF entities, so another dependency on the database.
@John: Do you have another understanding of it?
In the end, it's all about trade-offs. Let's follow your approach and analyze it.
Database - A big design on the database side means, almost in all cases, to have business rules implemented at that level. Also, the specific ways of representing the data will influence the overall design.
Data layer - If the database is the main pillar, it will influence the design of the entities, regardless if an ORM framework will be used or not. It will be heavily dependent on the database design and will propagate this dependency to the above layer instead of hiding it. It is going to become even worst if Entity Framework is used because the so-called entities will be just a projection of the database structure.
Business layer - As long as the main logic is in the database, there is almost no need for it. This layer will be, usually, pretty thin, and will contain logic to act upon the EF entities from the data layer, so the storage details will pop-up to this layer.
The Presentation layer - will be required to know about the EF entities, so another dependency on the database.
@John: Do you have another understanding of it?
I am thinking it a bit different...
Database...while it has no logic...it's design follow the rules on BLL....avoid unnecessary manipulations
DAL .... it has only basic logic to make the I/O of data...probably some minimum manipulation to facilitate the BLL
BLL...it has everything going on
PL ...it should be as abstract based as possible.
Database...while it has no logic...it's design follow the rules on BLL....avoid unnecessary manipulations
DAL .... it has only basic logic to make the I/O of data...probably some minimum manipulation to facilitate the BLL
BLL...it has everything going on
PL ...it should be as abstract based as possible.
Maybe i typed it wrong...i meant it should somewhat "free" in the concept that today is a desktop form ..tomorrow is a web page.
Hi,
I'll make my final statement here: my suggestion is to focus on the details related to the problem domain and create the models (classes, structs, value objects) storage agnostic. In this way, you'll not get any constraint related to the models and business rules. Postpone as much as possible the details related to storage, UI, etc. Keep the database, UI and other dependencies as simple as possible. Don't bother with WCF if you want a middle layer. It will overcomplicate the interface between layers and will make the debug to be difficult. Favor lightweight data exchange content as JSON over HTTPS. Implement each layer as a service with a well-defined API. Avoid dependencies as much as possible.
I'll make my final statement here: my suggestion is to focus on the details related to the problem domain and create the models (classes, structs, value objects) storage agnostic. In this way, you'll not get any constraint related to the models and business rules. Postpone as much as possible the details related to storage, UI, etc. Keep the database, UI and other dependencies as simple as possible. Don't bother with WCF if you want a middle layer. It will overcomplicate the interface between layers and will make the debug to be difficult. Favor lightweight data exchange content as JSON over HTTPS. Implement each layer as a service with a well-defined API. Avoid dependencies as much as possible.
Sorry all was off for the holidays, a lot of reading / researching to do.
Give me a day and I'll post with follow ups or close this out.
Thanks,
Kyle
Give me a day and I'll post with follow ups or close this out.
Thanks,
Kyle
Sorry all for the delays in closing. Lots to think about but this makes it a bit clearer.
Focusing on the business rules and building the classes to do that makes sense. Once the classes are in place we can extend out to store them the best way we see fit and how we want to present them to the end user.
Focusing on the business rules and building the classes to do that makes sense. Once the classes are in place we can extend out to store them the best way we see fit and how we want to present them to the end user.
-
![]()
Solutionfinancial application/systems database -
![]()
ArticleGeneral Data Protection Regulation (GDPR) practical impact on software architecture -
![]()
VideoHow to install the Office 2016 desktop applications that come with the free trial of Office 365 Home -
![]()
Cloud Class®Certification: IC3 GS4 Internet Core Competency Global Standard 4 - Key Applications
-
![]()
received a Solution
How can i confirm and ensure that my application reads and uses information in my appconfig file -
![]()
wrote an Article
Application Detection Using Powershell -
![]()
created a Video
![]()
How to get a free trial of Office 365 with the Office 2016 desktop applications
-
Explore Cloud Class® ![]()
70-643 - Windows Server 2008 Applications Infrastructure
Premium Content
You need an Expert Office subscription to comment.Start Free Trial