At Growth Acceleration Partners, we’re specialists in software development. We build custom software solutions, mobile applications and web applications. As software grows in complexity and clients demand more functionality from their existing or new systems, what can you do to keep ahead of curve?
What patterns and practices can you implement to make your source code easier to maintain and more enjoyable to work with?
In this post, we talk about some patterns and best practices you can adopt to address these points and discuss some of the layers you’ll find in a lot of web applications.
Data Persistence
In most “line of business” (LOB) web applications, you’ll likely be working with relational data. One customer – many orders, one patient – many test results and so on.
If you’re implementing a data store such as Microsoft SQL Server or Oracle, then you’ll want to leverage stored procedures for all data related CRUD tasks (create, retrieve, update and delete).
[bctt tweet=”Best practices you can implement to make your source code easier to maintain” username=”@GAPapps”]
Why?
Here are just some of the benefits associated with using stored procedures:
- Execution plan retention and reuse
- Encapsulation of business rules and policies
- Application modularization
- Sharing of application logic between applications
- Access to database objects that is both secure and uniform
- Consistent, safe data modification
- Centralized security, administration, and maintenance for common routines
But I’m using Entity Framework?
That’s ok, you can execute stored procedures via Entity Framework too!
Business Rules Layer
All domain logic should be placed in the business logic layer. Sometimes it’s not always pragmatic to encapsulate every business rule in a class library or API but strive to achieve this wherever you can. It pays enormous dividends, especially if you’re working on an enterprise system.
Imagine, for example, you have complex calculations or processes that are executed throughout many lines of code in your system. These lines of code are spread between screens and hidden under button clicks or MVC Controller methods.
Later, new system requirements dictate that this logic must be exposed via a web service.
How can you quickly and easily do this if the logic is spread across the system?
You can’t.
If, on the other hand, you had baked these business rules into a .NET Class Library or API, you could simply have added a reference to the Class Library and would have instant access to the methods from the new web service. Adopting this approach saves time and money in the long term.
Where do I put the business logic layer in my .NET MVC application?
Your Controller should be light and have minimal lines of code. Your business logic layer can be invoked within the Controller. One pattern you can implement to ensure your Controller code contains minimal code is called the Orchestrator.
This raises the issue of View Models and Domain Models as:
- the business logic layer should only deal with domain models
- the UI should only deal with view models
[bctt tweet=”How to build a well-architected web app #bestpractices” username=”GAPapps”]
View Models
When architecting your MVC application, always use strongly typed View Models.
Why?
- View Models make it easier to handle data in the View
- You get Intellisense support during development
- It shields you from using ViewBag, ViewData or TempData
- It’s much cleaner and simpler!
Domain Models
The Domain Model represents the problem domain you’re working in. You can think of each domain model as being “data plus behaviors”. Domain models are often hierarchical and made up of complex types.
A “Person” object, for example, may have a property of type “Address” which contains additional properties such as street number and zip code.
The View Model in contrast is just a DTO. Flat, and made entirely of primitive types such as strings. Ideal for binding to the user interface or View.
User Interface (Views)
Web application user interfaces have come a long way from the 90s. Users now expect responsive interfaces and are accustomed to sites being responsive and mobile device friendly. Web applications are viewed in devices with various screen dimensions and resolutions so it’s important to consider this when building your web application.
From an ASP.NET perspective, what can you do to ensure that you’re giving users the best experience possible and ensure that your source code is easy for your developers to maintain and build? Here are some points to consider when writing Views.
- Use Bootstrap wherever you can.
- Views should not contain any business logic and must be clean. All business logic must be performed inside the controllers.
- No JavaScript in Views
- Don’t place your JavaScript code inside the views. Create separate script files for JavaScript.
- Write an HtmlHelper for Conditions
- If you find yourself writing an “if” statement write an HtmlHelper for it to hide if else code from the view.
- When binding data, use View Models
Performance and maintainability
We’ve covered data access, business rules and the user interface. These form the high-level layers of any well-architected system. By isolating these components you’ll enforce standard development practices thereby making your source code simpler for developers to understand and maintain.
Here are some final tips to consider.
Base Controllers
Do you have common logic that is used across every Controller? If so, then introduce a Base Controller and make sure every Controller you implement inherits from the Base Controller. By doing this, you can affect change across every Controller in your project in one place.
Caching
Do you have lists of common datasets that are used repeatedly throughout your web application? Add these datasets to the Application Cache when your application initializes (in the Global.asax code file). This will reduce the traffic from going backward and forwards to the database.
AutoMapper
When implementing View Models and Domain Models, you’ll find yourself writing lots of boilerplate “mapping code” when you convert View Models to Domain Models and vice versa. This code is time-consuming and tedious. Fortunately, you can use a product called AutoMapper, which as the name suggests, reduces this tedious task down to a few lines of code.
Summary
In this article, we’ve discussed how to layer your web application to ensure it follows best practices in terms of the system architecture. We’ve also explained the rationale behind these principles and highlighted key areas where you can improve application performance.
Here at Growth Acceleration Partners (GAP), we’re experts in software development. Our development teams have been writing web applications for years. Based in Austin, TX, our developers are located nearby in Latin America with primary development centers in Costa Rica and Colombia.
With this proximity, GAP has become the go-to outsource partner for software development. With similar time zones and a culture that mirrors Western values, GAP has satisfied hundreds of US-based companies. GAP’s developers deliver on time in a cost-effective manner solving business problems for our partners. We can provide your organization with a team of highly qualified data scientists and engineers, for a wide variety of projects.
You can find out more about our services on our website here.
Why not arrange a call with us?
