This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Creating a Business Logic Layer (C#)

  • 9 contributors

by Scott Mitchell

Download PDF

In this tutorial we'll see how to centralize your business rules into a Business Logic Layer (BLL) that serves as an intermediary for data exchange between the presentation layer and the DAL.

Introduction

The Data Access Layer (DAL) created in the first tutorial cleanly separates the data access logic from the presentation logic. However, while the DAL cleanly separates the data access details from the presentation layer, it does not enforce any business rules that may apply. For example, for our application we may want to disallow the CategoryID or SupplierID fields of the Products table to be modified when the Discontinued field is set to 1, or we might want to enforce seniority rules, prohibiting situations in which an employee is managed by someone who was hired after them. Another common scenario is authorization perhaps only users in a particular role can delete products or can change the UnitPrice value.

In this tutorial we'll see how to centralize these business rules into a Business Logic Layer (BLL) that serves as an intermediary for data exchange between the presentation layer and the DAL. In a real-world application, the BLL should be implemented as a separate Class Library project; however, for these tutorials we'll implement the BLL as a series of classes in our App_Code folder in order to simplify the project structure. Figure 1 illustrates the architectural relationships among the presentation layer, BLL, and DAL.

The BLL Separates the Presentation Layer from the Data Access Layer and Imposes Business Rules

Figure 1 : The BLL Separates the Presentation Layer from the Data Access Layer and Imposes Business Rules

Step 1: Creating the BLL Classes

Our BLL will be composed of four classes, one for each TableAdapter in the DAL; each of these BLL classes will have methods for retrieving, inserting, updating, and deleting from the respective TableAdapter in the DAL, applying the appropriate business rules.

To more cleanly separate the DAL- and BLL-related classes, let's create two subfolders in the App_Code folder, DAL and BLL . Simply right-click on the App_Code folder in the Solution Explorer and choose New Folder. After creating these two folders, move the Typed DataSet created in the first tutorial into the DAL subfolder.

Next, create the four BLL class files in the BLL subfolder. To accomplish this, right-click on the BLL subfolder, choose Add a New Item, and choose the Class template. Name the four classes ProductsBLL , CategoriesBLL , SuppliersBLL , and EmployeesBLL .

Add Four New Classes to the App_Code Folder

Figure 2 : Add Four New Classes to the App_Code Folder

Next, let's add methods to each of the classes to simply wrap the methods defined for the TableAdapters from the first tutorial. For now, these methods will just call directly into the DAL; we'll return later to add any needed business logic.

If you are using Visual Studio Standard Edition or above (that is, you're not using Visual Web Developer), you can optionally design your classes visually using the Class Designer . Refer to the Class Designer Blog for more information on this new feature in Visual Studio.

For the ProductsBLL class we need to add a total of seven methods:

  • GetProducts() returns all products
  • GetProductByProductID(productID) returns the product with the specified product ID
  • GetProductsByCategoryID(categoryID) returns all products from the specified category
  • GetProductsBySupplier(supplierID) returns all products from the specified supplier
  • AddProduct(productName, supplierID, categoryID, quantityPerUnit, unitPrice, unitsInStock, unitsOnOrder, reorderLevel, discontinued) inserts a new product into the database using the values passed-in; returns the ProductID value of the newly inserted record
  • UpdateProduct(productName, supplierID, categoryID, quantityPerUnit, unitPrice, unitsInStock, unitsOnOrder, reorderLevel, discontinued, productID) updates an existing product in the database using the passed-in values; returns true if precisely one row was updated, false otherwise
  • DeleteProduct(productID) deletes the specified product from the database

ProductsBLL.cs

The methods that simply return data GetProducts , GetProductByProductID , GetProductsByCategoryID , and GetProductBySuppliersID are fairly straightforward as they simply call down into the DAL. While in some scenarios there may be business rules that need to be implemented at this level (such as authorization rules based on the currently logged on user or the role to which the user belongs), we'll simply leave these methods as-is. For these methods, then, the BLL serves merely as a proxy through which the presentation layer accesses the underlying data from the Data Access Layer.

The AddProduct and UpdateProduct methods both take in as parameters the values for the various product fields and add a new product or update an existing one, respectively. Since many of the Product table's columns can accept NULL values ( CategoryID , SupplierID , and UnitPrice , to name a few), those input parameters for AddProduct and UpdateProduct that map to such columns use nullable types . Nullable types are new to .NET 2.0 and provide a technique for indicating whether a value type should, instead, be null . In C# you can flag a value type as a nullable type by adding ? after the type (like int? x; ). Refer to the Nullable Types section in the C# Programming Guide for more information.

All three methods return a Boolean value indicating whether a row was inserted, updated, or deleted since the operation may not result in an affected row. For example, if the page developer calls DeleteProduct passing in a ProductID for a non-existent product, the DELETE statement issued to the database will have no affect and therefore the DeleteProduct method will return false .

Note that when adding a new product or updating an existing one we take in the new or modified product's field values as a list of scalars as opposed to accepting a ProductsRow instance. This approach was chosen because the ProductsRow class derives from the ADO.NET DataRow class, which doesn't have a default parameterless constructor. In order to create a new ProductsRow instance, we must first create a ProductsDataTable instance and then invoke its NewProductRow() method (which we do in AddProduct ). This shortcoming rears its head when we turn to inserting and updating products using the ObjectDataSource. In short, the ObjectDataSource will try to create an instance of the input parameters. If the BLL method expects a ProductsRow instance, the ObjectDataSource will try to create one, but fail due to the lack of a default parameterless constructor. For more information on this problem, refer to the following two ASP.NET Forums posts: Updating ObjectDataSources with Strongly-Typed DataSets , and Problem With ObjectDataSource and Strongly-Typed DataSet .

Next, in both AddProduct and UpdateProduct , the code creates a ProductsRow instance and populates it with the values just passed in. When assigning values to DataColumns of a DataRow various field-level validation checks can occur. Therefore, manually putting the passed in values back into a DataRow helps ensure the validity of the data being passed to the BLL method. Unfortunately the strongly-typed DataRow classes generated by Visual Studio do not use nullable types. Rather, to indicate that a particular DataColumn in a DataRow should correspond to a NULL database value we must use the SetColumnNameNull() method.

In UpdateProduct we first load in the product to update using GetProductByProductID(productID) . While this may seem like an unnecessary trip to the database, this extra trip will prove worthwhile in future tutorials that explore optimistic concurrency. Optimistic concurrency is a technique to ensure that two users who are simultaneously working on the same data don't accidentally overwrite one another's changes. Grabbing the entire record also makes it easier to create update methods in the BLL that only modify a subset of the DataRow's columns. When we explore the SuppliersBLL class we'll see such an example.

Finally, note that the ProductsBLL class has the DataObject attribute applied to it (the [System.ComponentModel.DataObject] syntax right before the class statement near the top of the file) and the methods have DataObjectMethodAttribute attributes . The DataObject attribute marks the class as being an object suitable for binding to an ObjectDataSource control , whereas the DataObjectMethodAttribute indicates the purpose of the method. As we'll see in future tutorials, ASP.NET 2.0's ObjectDataSource makes it easy to declaratively access data from a class. To help filter the list of possible classes to bind to in the ObjectDataSource's wizard, by default only those classes marked as DataObjects are shown in the wizard's drop-down list. The ProductsBLL class will work just as well without these attributes, but adding them makes it easier to work with in the ObjectDataSource's wizard.

Adding the Other Classes

With the ProductsBLL class complete, we still need to add the classes for working with categories, suppliers, and employees. Take a moment to create the following classes and methods using the concepts from the example above:

CategoriesBLL.cs

  • GetCategories()
  • GetCategoryByCategoryID(categoryID)

SuppliersBLL.cs

  • GetSuppliers()
  • GetSupplierBySupplierID(supplierID)
  • GetSuppliersByCountry(country)
  • UpdateSupplierAddress(supplierID, address, city, country)

EmployeesBLL.cs

  • GetEmployees()
  • GetEmployeeByEmployeeID(employeeID)
  • GetEmployeesByManager(managerID)

The one method worth noting is the SuppliersBLL class's UpdateSupplierAddress method. This method provides an interface for updating just the supplier's address information. Internally, this method reads in the SupplierDataRow object for the specified supplierID (using GetSupplierBySupplierID ), sets its address-related properties, and then calls down into the SupplierDataTable 's Update method. The UpdateSupplierAddress method follows:

Refer to this article's download for my complete implementation of the BLL classes.

Step 2: Accessing the Typed DataSets Through the BLL Classes

In the first tutorial we saw examples of working directly with the Typed DataSet programmatically, but with the addition of our BLL classes, the presentation tier should work against the BLL instead. In the AllProducts.aspx example from the first tutorial, the ProductsTableAdapter was used to bind the list of products to a GridView, as shown in the following code:

To use the new BLL classes, all that needs to be changed is the first line of code simply replace the ProductsTableAdapter object with a ProductBLL object:

The BLL classes can also be accessed declaratively (as can the Typed DataSet) by using the ObjectDataSource. We'll be discussing the ObjectDataSource in greater detail in the following tutorials.

The List of Products is Displayed in a GridView

Figure 3 : The List of Products is Displayed in a GridView ( Click to view full-size image )

Step 3: Adding Field-Level Validation to the DataRow Classes

Field-level validation are checks that pertains to the property values of the business objects when inserting or updating. Some field-level validation rules for products include:

  • The ProductName field must be 40 characters or less in length
  • The QuantityPerUnit field must be 20 characters or less in length
  • The ProductID , ProductName , and Discontinued fields are required, but all other fields are optional
  • The UnitPrice , UnitsInStock , UnitsOnOrder , and ReorderLevel fields must be greater than or equal to zero

These rules can and should be expressed at the database level. The character limit on the ProductName and QuantityPerUnit fields are captured by the data types of those columns in the Products table ( nvarchar(40) and nvarchar(20) , respectively). Whether fields are required and optional are expressed by if the database table column allows NULL s. Four check constraints exist that ensure that only values greater than or equal to zero can make it into the UnitPrice , UnitsInStock , UnitsOnOrder , or ReorderLevel columns.

In addition to enforcing these rules at the database they should also be enforced at the DataSet level. In fact, the field length and whether a value is required or optional are already captured for each DataTable's set of DataColumns. To see the existing field-level validation automatically provided, go to the DataSet Designer, select a field from one of the DataTables and then go to the Properties window. As Figure 4 shows, the QuantityPerUnit DataColumn in the ProductsDataTable has a maximum length of 20 characters and does allow NULL values. If we attempt to set the ProductsDataRow 's QuantityPerUnit property to a string value longer than 20 characters an ArgumentException will be thrown.

The DataColumn Provides Basic Field-Level Validation

Figure 4 : The DataColumn Provides Basic Field-Level Validation ( Click to view full-size image )

Unfortunately, we can't specify bounds checks, such as the UnitPrice value must be greater than or equal to zero, through the Properties window. In order to provide this type of field-level validation we need to create an event handler for the DataTable's ColumnChanging event. As mentioned in the preceding tutorial , the DataSet, DataTables, and DataRow objects created by the Typed DataSet can be extended through the use of partial classes. Using this technique we can create a ColumnChanging event handler for the ProductsDataTable class. Start by creating a class in the App_Code folder named ProductsDataTable.ColumnChanging.cs .

Add a New Class to the App_Code Folder

Figure 5 : Add a New Class to the App_Code Folder ( Click to view full-size image )

Next, create an event handler for the ColumnChanging event that ensures that the UnitPrice , UnitsInStock , UnitsOnOrder , and ReorderLevel column values (if not NULL ) are greater than or equal to zero. If any such column is out of range, throw an ArgumentException .

ProductsDataTable.ColumnChanging.cs

Step 4: Adding Custom Business Rules to the BLL's Classes

In addition to field-level validation, there may be high-level custom business rules that involve different entities or concepts not expressible at the single column level, such as:

  • If a product is discontinued, its UnitPrice cannot be updated
  • An employee's country of residence must be the same as their manager's country of residence
  • A product cannot be discontinued if it is the only product provided by the supplier

The BLL classes should contain checks to ensure adherence to the application's business rules. These checks can be added directly to the methods to which they apply.

Imagine that our business rules dictate that a product could not be marked discontinued if it was the only product from a given supplier. That is, if product X was the only product we purchased from supplier Y , we could not mark X as discontinued; if, however, supplier Y supplied us with three products, A , B , and C , then we could mark any and all of these as discontinued. An odd business rule, but business rules and common sense aren't always aligned!

To enforce this business rule in the UpdateProducts method we'd start by checking if Discontinued was set to true and, if so, we'd call GetProductsBySupplierID to determine how many products we purchased from this product's supplier. If only one product is purchased from this supplier, we throw an ApplicationException .

Responding to Validation Errors in the Presentation Tier

When calling the BLL from the presentation tier we can decide whether to attempt to handle any exceptions that might be raised or let them bubble up to ASP.NET (which will raise the HttpApplication 's Error event). To handle an exception when working with the BLL programmatically, we can use a try...catch block, as the following example shows:

As we'll see in future tutorials, handling exceptions that bubble up from the BLL when using a data Web control for inserting, updating, or deleting data can be handled directly in an event handler as opposed to having to wrap code in try...catch blocks.

A well architected application is crafted into distinct layers, each of which encapsulates a particular role. In the first tutorial of this article series we created a Data Access Layer using Typed DataSets; in this tutorial we built a Business Logic Layer as a series of classes in our application's App_Code folder that call down into our DAL. The BLL implements the field-level and business-level logic for our application. In addition to creating a separate BLL, as we did in this tutorial, another option is to extend the TableAdapters' methods through the use of partial classes. However, using this technique does not allow us to override existing methods nor does it separate our DAL and our BLL as cleanly as the approach we've taken in this article.

With the DAL and BLL complete, we're ready to start on our presentation layer. In the next tutorial we'll take a brief detour from data access topics and define a consistent page layout for use throughout the tutorials.

Happy Programming!

About the Author

Scott Mitchell , author of seven ASP/ASP.NET books and founder of 4GuysFromRolla.com , has been working with Microsoft Web technologies since 1998. Scott works as an independent consultant, trainer, and writer. His latest book is Sams Teach Yourself ASP.NET 2.0 in 24 Hours . He can be reached at [email protected]. or via his blog, which can be found at http://ScottOnWriting.NET .

Special Thanks To

This tutorial series was reviewed by many helpful reviewers. Lead reviewers for this tutorial were Liz Shulok, Dennis Patterson, Carlos Santos, and Hilton Giesenow. Interested in reviewing my upcoming MSDN articles? If so, drop me a line at [email protected].

Previous Next

Was this page helpful?

Submit and view feedback for

Additional resources

  • 90% Refund @Courses
  • Engineering Mathematics
  • Discrete Mathematics
  • Operating System
  • Computer Networks
  • Digital Logic and Design
  • C Programming
  • Data Structures
  • Theory of Computation
  • Compiler Design
  • Computer Org and Architecture

Related Articles

  • DSA to Development
  • Measures of Query Cost in DBMS
  • What is EII(Enterprise Information Integration)?
  • Hardware RAID
  • Audit Trail
  • Virtual Private Database (VPD)
  • Predicate Locking
  • Data-Access Layer
  • What is Report Generator?
  • What is Software RAID?
  • Difference Between Data Mining and Data Analysis
  • Query-Execution Plan in SQL
  • Weak Levels of Consistency
  • Difference Between Hardware RAID vs Software RAID
  • Introduction to NoSQL Cloud Database Services
  • Double Buffering
  • Failure Classification in DBMS
  • ODBS Full Form
  • Access Types in DBMS
  • Strategies For Migrating From SQL to NoSQL Database

Business-Logic Layer

In this article, we are going to learn about the Business Logic Layer in Database Management systems. The Business Logic Layer also known as BLL act as an intermediate between the Presentation Layer and the Data Access Layer (DAL). This layer handles the business logic, business rules as well as calculations. It tells how the data from the database can be used, what it can perform, and what can not within its application.

The Business-Logic Layer (BLL) is a component of a software architecture that is responsible for implementing the business logic of an application. It sits between the presentation layer (e.g., the user interface) and the data access layer (e.g., the database), and is responsible for processing and manipulating data before it is presented to the user or stored in the database.

The BLL is responsible for performing tasks such as: -Validating input data to ensure that it meets the necessary business rules and constraints. -Performing calculations and transformations on data, as required by the business logic. -Enforcing business rules and policies, such as access control and security. -Communicating with the data access layer to retrieve and store data. -Handling errors and exceptions.

The BLL is designed to be reusable and independent of the user interface and data storage implementation. This allows the application to be easily modified or extended without affecting the underlying business logic.

The BLL is also responsible for managing the workflows and the use cases of the application, by handling the communication between the different layers, and by implementing the rules and constraints of the business.

In summary, The Business-Logic Layer (BLL) is a component of a software architecture that is responsible for implementing the business logic of an application. It sits between the presentation layer and the data access layer, and is responsible for processing and manipulating data before it is presented to the user or stored in the database. It also manages the workflows and the use cases of the application, and it is designed to be reusable and independent of the user interface and data storage implementation.

  • Presentation Layer: The layer at which users interact with the application and the final data will be visible to the users at this interface. It acts as an interface between the user and the application.
  • Business Logic Layer: It acts as an intermediate between the Presentation and the Data Access Layer.
  • Data Access Layer: The layer at which the data is managed.

Business Logic Layer

Business Logic Layer

  • All the three layers above play an important role in building an application
  • The business logic layer manages the communication between the database and the presentation layer.

Example: In an application, when the user access it or write queries in it with the help of a presentation or user interface layer the business logic layer helps the user to get a response to the asked queries by transferring it to the Data Access layer which further processes the query and give the suitable result to a business logic layer which is further transferred to the presentation layer which makes it visible to the user.

Due to the less clarity in defining the Business logic layer, some business domains like Microsoft and Apple excluded the BLL from their applications which leads to difficulty in code maintenance. A better approach is to build an application that supports multiple different user Interfaces.

Advantages of Business Logic Layer:

  • Code Maintenance is easy: Maintaining the code will be easy when we are using the Business Logical Layer as it supports multitier architecture. By using this we can easily determine any kind of change in the code.
  • Security: This architecture provides us the security as we can see that the Presentation layer doesn’t directly interact with the Data Access Layer which prevents it from any kind of data loss and ensures that the data is secure at the Data layer.
  • Application releases: It makes application release rollout easy. Because the Business Logic Layer is the only one to be updated every time then we do not need other layers of architecture i.e. the Presentation layer and the Data Access Layer.
  • Ease of learning: It is easy to learn because the learner has to specialize only in the presentation, data, and business layer to more quickly learn the specific parts of the application. The development time taken by the application will be small as all the layers can work together at the same time.

Disadvantages of Business Logic Layer:

  • Expensive: It will be very difficult and expensive to install and maintain this layer in databases.
  • Source control is very difficult to perform properly with existing procedures.
  • It makes it difficult to use the code, again and again, such that it decreases code reusability .

Applications of Business Logic Layer:

  • BLL has a major application in building multi-tier applications.
  • It is most commonly used in creating component-based applications.

Unlock the Power of Placement Preparation! Feeling lost in OS, DBMS, CN, SQL, and DSA chaos? Our Complete Interview Preparation Course is the ultimate guide to conquer placements. Trusted by over 100,000+ geeks, this course is your roadmap to interview triumph. Ready to dive in? Explore our Free Demo Content and join our Complete Interview Preparation course.

Please Login to comment...

  • Computer Subject
  • laxmishinde5t82

Improve your Coding Skills with Practice

 alt=

What kind of Experience do you want to share?

The Reformed Programmer

I am a freelance .NET Core back-end developer

Architecture of Business Layer working with Entity Framework

Jonathan Crosby asked a question on one of my GenericServices   GitHub projects about how to handle a Business Layer. I thought it was a good question so I have written an article to detail my approach to building business layers that use Entity Framework.

UPDATE 2016: See new, improved approach here

I have revisited this topic and refined my approach to Business Logic using EF. I suggest you read the new article called Architecture of Business Layer working with Entity Framework (Core and v6) – revisited.

UPDATE 2017: Book Entity Framework Core in Action

I have been commissioned my Manning Publishing to write the book Entity Framework Core in Action , in which chapter 4 is all about Business Logic in an Entity Framework Core environment (but the ideas are applicable to EF 6 too). 

This original article is old, but I have kept it because of all the comments.

What is the Business Layer?

The Business Layer is the place where all the business/domain logic, i.e. rules that are particular to the problem that the application has been built to handle, lives. This might be salary calculations, data analysis modelling, or workflow such as passing a order through different stages.

You can get a more in-depth coverage of the overall architecture in this  Simple-Talk article .

Aside: While having all the business rules in the Business Layer is something we should always strive for I find that in practice some issues go outside the Business Layer for good reasons. For instance validation of date often flows up to the Presentation Layer so that the user gets early feedback. It may also flow down to the database, which checks data written to the database, to ensure database integrity.Other business logic appears in the Presentation Layer, like not allowing users to buy unless they provide a credit card, but the status should be controlled by the Business Layer. Part of the skill is to decide whether what you are doing is justifiable or will come back and bite you later! I often get that wrong, but hopefully I learn from my mistakes.

My philosophy on the Business Layer

I have written numerous applications for predictive modelling of various healthcare issues, all of which have some quite complex business logic. Over the years I have tried different ways of organising these applications and I have come with one key philosophy – that the “ The Business Layer is King “, i.e. its design and needs drives everything else.

I am a big fan of Domain-Driven Design (DDD) which has the same philosophy and provides some approaches to help keep the business logic at the forefront of any design. Here are some of the approaches from DDD that drive my designs.

1. The Business Layer defines the data structures

The problem we are trying to solve, often called the “Domain Model”, is the heart of the problem. These can be complex so the core data structures should be defined by, and solely focused on the business problem. How it is stored and how it is viewed are secondary issues.

2. The Business Layer should find persistence of data simple

While DDD accepts that the way data is stored/persisted will have an affect on the design (see Eric Evans book , page 159) the aim is to allow Business Layer code treat the database as almost an in-memory collection. Entity Framework really helps with this.

The architecture of my Business Layer

Based on the philosophy listed above the implementation I use has the following characteristics.

1. I use Adapters widely

As I said above the Business Layer is in control of the data structures – what makes the most sense for the Business Layer is what it does. This means it normally deals in data classes and/or entity keys (DDD term for the primary keys of data/entity classes).

This means the data needed/produced by the business logic is often not in the right format for communicating to the user and/or other external APIs. I therefore use Adapters, i.e. something that transforms the data to/from what the business logic. The Service Layer does this for the Business to Presentation layer communication while external services are adapted inside the Data Layer.

Further reading:

  • See Alistair Cockburn’s Hexagonal/Adapter-Port architecture . My applications are mainly in this style. I use Dependency Injection to link layers.
  • DDD call these anti-corruption layer – See Eric Evans’ talk on DDD in which he talks about different ways to adapt across Bounded Contexts (whole talk is great. Skip to 20mins in for part on linking bounded contexts).

2. The Business Layer uses EF directly

My early applications used the repository pattern and UnitOfWork pattern . However as EF has improved, and I have learnt more I have moved over to using EF directly in the Business Layer.

I found that the repository pattern in the end got in the way and made life much harder. Going for direct EF access allows the developer to access all the features of EF and stops some of the ranger tortuous approaches I used to use with repositories.

You can read more about this in my two blog posts:

  • Is the Repository pattern useful with Entity Framework?
  • Is the Repository pattern useful with Entity Framework? – part 2

3. The Business Layer does not do the final data save.

This is subtle, but I have found this very helpful. I don’t want the Business Layer to really know about saving data. I can’t totally ignore the data access code, in my case Entity Framework (EF), in the Business Layer, but I do minimise it.

Therefore Business Layer methods adds/inserts new data into the in-memory data classes or simply changes any loaded data from the database. However the Business Layer never calls EF’s SaveChanges. That is done in the Service Layer that called it.

Why do I find this useful? There are a number of reasons:

  • The Business Layer does not have to handle database validation errors, which can occur when ‘SaveChanges’ is called. The Service Layer does that, which has more information available to it on what is going on.
  • I know that all the data will be saved in one transaction. It is either there or its not.
  • If I need to chain multiple business methods I can use a transaction scope to rollback changes if one of the later methods fails.
  • The Service Layer can check other things to decide whether the data should be saved. I use this to allow users to save/not save on warnings.
  • It makes the Unit Testing of the Business Logic much easier as the database has not been changed. Most of my Business Logic has a property holding the data structures about to be written, so I can just check that.

Note: The discarding of data by not calling ‘SaveChanges’ only works in situation where each call has its own DbContext. This is the state in a web application as each HTTP request gets a new DbContext.

My implementation: GenericActions library

I have a library called GenericActions which has a very similar interface to the GenericServices library. Note: This isn’t an open-source library, but is part of my proprietary Rapid-Build™ library set that I use when building applications for clients.

Like GenericServices GenericActions can either work directly with the business class or more usually via a Data Transfer Object (DTO) – See Why DTO? in the GenericServices documentation for more on DTOs. It uses DI to pull in a Business Layer class, hence making sure the Business Class can pick up any services it needs through constructor injection.

A typical call of a business method at the MVC controller level looks very much like a GenericServices call.

The main difference is the definition of the service (see line 4 above). The service contains the interface of the Business Layer class that contains the method it needs to call. DI is used to inject the right class into the service.

In the case above the action only returned a status to say if it was successful or not. However other Business Layer methods may need to return data, so there is another type of call that returns a class. This class can either be the class result produced by the business class or another DTO to do the conversion.

You can read about the way I implemented the GenericActions (and GenericServices) library in my new post, Using .NET Generics with a type derived at runtime.

Conclusions

Because GenericServices is focused on the database to/from Presentation Layer communication I have not described my view of the Business Layer. Hopefully this article fills in that gap by describing the ways and wherefores of the Business Layer in my  architectural view of applications.

Happy coding!

guest

Sorry but i hardly disagree on the repository pattern. People get confused on its use over EF. While using Repo + uow + EF is of course non sense, using repo + EF is the way to go. Using Ef directly in the BLL goes against separation of concern as it induce tight coupling to a framework. Also, say you, one day, want to change your ORM (for performance concern, for example) using the repo pattern will alow you to do this easily without having to make lot of changes in your BLL.

Jon Smith

Hi @Veillet Alexandre,

Thanks for your comment. While I understand where you are coming from my real-life experience has shown me that hiding all the EF inside a repository pattern is really hard to do well. That was what I was previously doing (see my two part article on that. The problem is that database accesses to get pretty complicated and the abstraction of a repository on top of the abstraction of EF I found really difficult to do well. It was so painful that taking the repositories away made my code so much better.

I realise I am locking myself into a specific ORM, EF, but again my experience is that once I start a project I rarely change the bigger libraries, which are in themselves an abstraction, I use as that is quite hard work. That means am fairly careful about choosing my key libraries at the start, but for a project taking less than say 1 year elapsed that I think is OK.

As for separation of concerns then, yep, I admit I sometimes I loose that. I try to use query objects as much as possible and I have a open-source library called GenericServices which hides the EF for many CRUD options. The other trick I use in my business logic is to place the EF access in a specific area of business code. That loads all the data and the rest of the business logic uses the classes directly as a in-memory set of classes (DDD style). This makes changing the EF code, say to improve performance, much easier as its all in one place.

I might sound a bit pragmatic but having used repositories a lot I know the pain there and using EF directly is, for me, a much better option. Clearly you do things differently and that’s fine. In the end a large part of programming today is picking the approach, libraries, patterns etc. that allow you to produce robust, well performing and adaptable applications in the most efficient way. We may differ in our approach but if we each achieve that goal then we are doing our job well.

That’s the thing people get confused the most about Repo + EF is not abstraction, it’s about isolation. UOW + REPO + EF would be an other layer of abstraction that would be unneeded of course. But from what you say you’re doing the isolation on the BLL layer which is exactly what i do thanks to REPO but i do it in the DAL layer where it should be since it “data” concern.

Yeah we don’t get to change ORM everyday so it’s not a big deal to not isolate it but to me the concern is to build different layer that are not tightly coupled which is, from my short experience, always overlooked by dev and architect which find themselve years later (in long term project) stuck on their architecture and previous choice and can’t upgrade their project at all.

For small project i have no problem going simple, but for professional development thinking about the future never hurts even if some principle (YAGNI) kinda go against thinking too beforehand, which i disagree with.

I never had much problem with Repositories in themselves, it’s merely a specialized Facade in the end. I know project can get messy over time but that’s the point to make your architecture as best as possible because not doing so will make the project even messier and faster … i had to deal with project where no structure was put in place and sql queries where directly made and mix with business code in the UI’s designer code so clearly that’s not great

Thanks for your comments. I think my attempts at Repos were an abstraction as well as Facade, as the repro hide how EF managed the data. The problem I had was its actually hard to hide EF as there are lots of little small things that get you. For instance updating a class requires for it to be tracked by EF and because EF is hidden you have to either check if it is tracked or use some EF magic to say its an update (which has problems). Believe me – it became hard work!

Good debate though!

mmm well that depends, I use POCO, and not DTO, which are my entities, so I can use them on every layer as they are also isolated in their own library. I have to agree that making DTOs in that data layer + POCOs in the other are quite the trouble and kind of unnecessary.

OK. I have a base project which every other project inherits that contains my POCO EF classes, but no DTOs. I mainly have DTOs in the service layer, where they may also use attributes/classes that are linked to my presentation layer, e.g. System.Web’s HtmlString. I also have DTOs in the Business Layer, but they are totally neutral of how that data is use and are not allowed to know anything about the layers above.

Hi Veillet,

I think I have finally come round to your view! I think my problem of understanding what you meant by the word ‘Repo’. ‘Repo’ to me is a big abstraction, but I see now that you see it only as a facade.

It took me building a whole e-commerce and then reviewing it to see your point of view! I have written a new article which uses a simple facade to isolate the EF code.

I like this new form a lot, and I think it is closer to what you were talking about.

Hi Jon Smith, I have read the new article and indeed this go more on the same way that i do, although i still go a bit more further but mostly for the sake of it since it would probably fall in the YAGNI spirit. In that article, you said that EF entities are good enough for the bisuness layer, which is not false. But, i think it doesn’t hurt to go beyond, why ? because it could come handy in some situation. What do i mean ? In DDD, it is adviced to separate your entities for each context, thus a User object in your business layer and a User in your Data layer aren’t/shouldn’t be the same. I give you that it’s a hassle to handle and i understand the need and choice to go the short way, especially if it’s possible (mostly on new project that have no legacy to support). But, in my short career again, i never saw one of those project where you didn’t have some old stuff to support which was poorly designed to begin with, and that is especially database … i have supported a database which model had been created more than 30 years ago now on principle that are, nowadays, outdated … and if i had been a bit more cultivated back when i had to do that. i would definetely have gone the way to have separate entities. Why is it good ? it is because you can design your business class purely on what they should look like. And then if the database you have to support already exist and has a strange model for a reason or an other, you can just use a mapper between the 2 layer, which is what i do, but the downside is that it is a big hassle to do so even with auto mappers anyway and you still have to handle EF behaviour for thing like update etc…. (since for example, you can’t just can’t create a new EF object and think it’ll update it, you have to load it from the db and update it the the information from the business object and then save it, which is heavy but bring more flexibility) but again it come in handy when your business object is represented by a single class and that for some reason, in the data layer your object is represented by 2 or more tables … Anyway, i am glad i helped you change your view on some point, repositories are facade, and i see them as such.

Thanks for your comments. I do take your point that when dealing with legacy systems the match between the database and the business logic may not be good. I have had the privilege on working new systems where this happens. However I have a new contract which involves access to an old database, albeit as a secondary source.

I will think about what you have said and see if I can update the new article to cover that.

Thanks again for you input.

I have moved this conversation to the new article. see this comment .

serdar bolum

I spent all my day to read your articles about Repository pattern vs. Generic service. As I was already in doubt using repository and UOW pattern in my project, your ideas make me convince a lot. Thank you.

There is something I couldn’t understand. Even you told about business layer here, I couldn’t see any code about it. The only code here is controller level and it calls directly service not business class. In addition, I checked your sample project “SampleMvcWebAppComplex”, but I couldn’t see business layer there as well. So I’m confused about relation between service and business layer and as if we can merge them into one layer.

Thanks in advance

Sorry there isn’t much code there as I was trying to get over the concepts, which fit in with the idea of using EF directly. As I said I do have a library called GenericActions, but its not open-source for two reasons. Firstly it is a lot more complicated than GenericServices (see this article for some of the problems), which makes documentation and examples quite difficult. Secondly having it private means there is a good reason for clients to hire me, as it makes me faster!

You can read another article where I talk more about how to use EF’s DbContext in the business layer, which I think is a very important issue to resolve. My business methods are allowed full access to any and all EF methods apart from `.SaveChanges()` or `.SaveChangesAsync()`. Calling either of those methods is definitely done at the Service Layer level, in my case by GenericActions, which acts as a pseudo Service Layer.

I can say the GenericActions feels very similar to GenericServices to use. The big difference is that it calls a method rather than accessing the database, that is why in the example above you see `IActionService service`, with the IBizGraderSetup being an interface to a method.

Felix Gondwe

Thanks for the article, really learning a lot from your articles. I am a newbie trying to decide Repository pattern vs EF. I was wondering if you have sample project for your GenericServices?

Sure. I don’t think a library is any good without good documentations & samples so I produced two sample projects, both with live sites so you can see them in action. If you go to the GenericServices site on github and read the README file it has links to the live sites and the source of both. Do also got to the GenericService’s Wiki which has lots of information, including an overview of the architecture.

PS. If you haven’t found them yet there are two articles on my blog about this subject – see the first article . This first article covers my own research/deliberations on the subject. In the second article, which is linked at the top of the first article, I reflect on life after I had made the change to a non-repository pattern.

Jasmine Phong

Thanks for your insight on using EF directly vs repository pattern. You’re really added a new dimension on my study of MVC. I’m a newbie to MVC and am trying to design a robust and scalable backend architecture for a new project at work. I noticed that the examples given in your posts and in the sample codes are using Code-first EF (as are most examples online). I’m curious as to whether I can also apply the GenericServices architecture to DB-first EF as well, since this is the approach our team has chosen to adopt.

Thanks in advance.

Hi Jasmine,

Glad you liked the article on EF directly vs repository pattern. This was a big change for me, but my Data Layer coding is much cleaner because of it.

On your question on using Code First with an existing database then I have written two articles about this – see https://thereformedprogrammer.net/entity-framework-working-with-an-existing-database/ for part one which deals with importing an existing database schema. These articles are also available on Simple-Talk – see https://www.simple-talk.com/dotnet/.net-framework/using-entity-framework-with-an-existing-database-data-access/ (useful if you want a print-friendly version).

One thing on EF Code First that is worth pointing out is that Code First CAN work with existing databases. Some of the early EF code was called Database First, so they called the next version Code First. However that has caused confusion. Code First is the primary way to use EF now and has a Reverse Engineering feature built in that allows you to create Code First classes and DbContext from a existing database – see https://msdn.microsoft.com/en-us/data/jj200620

My articles mentioned above pull out some of subtle issues around Reverse Engineering that you and your team might find it useful. There is also an example application to go with the articles which can be found here https://github.com/JonPSmith/SampleMvcWebAppComplex with a live site at http://complex.samplemvcwebapp.net/ . This project uses GenericServices.

Thanks for the prompt reply.

Yes, I understand I can use “Code First” EF on an existing database via Reverse Engineering. But we already have some “stuff” built using “Database First” (i.e. EDMX). The reason why we prefer the “Database First” approach is that the database designer may not be part of the “coding” team, and we literally design the database (tables, views and stored procedures) first, before coding on top of the database. For us, stored procedures are a necessity, and we find it easier to “bring in” stored procedures into EF via “Database First” approach. I’m not sure if we’re able to do that via “Code First”.

My main concern right now is since the DbContext needs to inherit IGenericServicesDbContext, how should go about making use of GenericServices together with the DbContext that has been generated from the EDMX.

Thanks again!

Ok, that makes sense. I haven’t used “Database First”/EDMX so I can’t give you a definitive answer. I see from the documentation that EDMX produces a DbContext. Obviously you don’t want to add the IGenericServicesDbContext to the generated code, but you could produce a partial class of the DbContext and add the interface to that. That is what I did in the SampleMvcWebAppComplex application.

The IGenericServicesDbContextis pretty basic, so I think it should work with any DbContext.

That sounds like a great idea! I’ll try it out and let you know if it works. 🙂

PS. Code First can use stored procedures now – it was added in EF 6. EF 6 adds lots of useful features which I mention my article.

I realise you don’t want to change, but I mention this for anyone else reading these comments.

Anders Baumann

Thank you some great articles. I completely agree with you on your point about the repository pattern and that it is better to use EF directly.

I have looked through the examples and documentation for GenericServices. I like your approach. I would really like to see the GenericActions library also. Any chance that you will make it public? Or is it possible to buy the source code?

As I understand you don’t mock the database but run unit tests against an actual database. That makes a lot of sense and it is also what Ayende and Jimmy Bogard recommends. Any tips on this approach? Do you use SQLLite?

Thanks in advance,

Thanks for your kind comments. Yes, contrasting my previous experience with using the repository pattern and now using EF directly it is much easier. However you do need to understand EF, but even with a repository pattern that was true anyway.

GenericActions isn’t public. I have a number of private libraries that make me more efficient on client projects – there needs to be some reason to make people want to pay for my services. Happy to collaborate with you on a paid project:)

GenericActions follows the same style as GenericServices, but is much more complex underneath because there are many more options when working with Business Logic. I am currently using GenericActions on a fairly complex web app which needs business logic to work. As always I am finding various ‘tweaks’ to make GenericActions more usable.

On the question of mocking the database I have made some progress since EF version 6 is out. There are a couple of EF articles (see https://msdn.microsoft.com/en-us/data/dn314429 and https://msdn.microsoft.com/en-us/data/dn314431 ). I have used this sometime when testing simple business logic, but not for anything complex. EF version 7 is said to have a fully implement memory database, which will be great for Unit Testing.

My approach is to use EF as the database, with the Unit Test App.Config pointing to a special Unit Test only database. I then either write my code so that it can work with a database that might have existing entries, or add a FixtureSetup method (I use NUnit) and wipe/reload the database when required. The main cost is the EF startup, which I haven’t found any way round.

Thanks for the thorough answer.

About commands/actions: I think I will try and implement them myself 🙂 I like Ayende’s approach where he has an ExecuteCommand method in the base controller: http://ayende.com/blog/154241/limit-your-abstractions-the-key-is-in-the-infrastructure . I also like his idea about property injection, which is explained here: http://www.jeremyskinner.co.uk/2008/11/08/dependency-injection-with-aspnet-mvc-action-filters/ . What do you think about this approach?

About testing: I have also used testing against an external database before. And I might do that again. But I just read this blog post http://web-matters.blogspot.com/2014/09/unit-testing-entity-framework-with-effort.html?m=1 where the author recommends the tool called Effort ( http://effort.codeplex.com/ ) “Effort is a powerful tool that enables a convenient way to create automated tests for Entity Framework based applications. It is basically an ADO.NET provider that executes all the data operations on a lightweight in-process main memory database instead of a traditional external database”. I think that it looks pretty interesting.

Thanks, Anders

Thanks for your thoughts – they provoke me to think these things through more.

About commands/actions: I use an interface to set a common call method in my business logic. I need an interface anyway because I use contructor dependency injection (DI) very heavily in my business logic – that makes for great separation and easy testing. Ayendes specifically says he has removed any dependencies so his method works well for him.

On the property injection from Jeremy Skinner it is clear that you HAVE to use property injection on MVC filters because of there design. Otherwise I always try to use construction injection as it makes testing easier. My rule, read years ago, is: use DI in application, but never in Unit Tests.

On Effort – wow, what a find! Thanks for that. I haven’t tried it, but if it does relational fixup, i.e. keys are filled in based on relationships, and vice versa, then it will be really helpful. When I have time I will look at it, but I have a few things stacked up at the moment. Note: EF 7 may change things here and have its own in-memory version, but Effort does look good as it is aimed at Unit Testing.

Yes, I agree that if you have many dependencies then Ayende’s design is less attractive. Do you inject the command interface in the controller action method like you do with your generic services? In that case how to decide what implementation of the interfaces that should be used in each case? Do you use the command handler pattern described here: https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91 ? The MediatR by Bogard also looks interesting: https://lostechies.com/jimmybogard/2014/12/17/mediatr-hits-1-0/ . Or the Shortbus which MediatR is inspired by: https://github.com/mhinze/ShortBus

Yes, I inject the command interface into the controller action is the same way as GenericServices. I love this approach, which means only the instances needed for that specific action are created. See short explanation at the end of this page http://samplemvcwebapp.net/Posts/CodeView

The interface for the business logic is more complicated than GenericServices because it has to include a reference to the Business Logic that must be run. For example a Controller action calling biz logic has the following pattern for the sync call:

public ActionResult SomeMvcAction(SomeInputDto dto, IActionService service)

The ISomeBizLogicInterface is linked to the specific business logic class that needs to be run. My GenericActions has a number of difference services interfaces, with options on whether there is an input and/or an output. The standard one takes and input class or Dto and returns a class look like this:

public interface ISomeBizLogicInterface: IGenericAction { }

If you read my other blog https://thereformedprogrammer.net/using-net-generics-with-a-type-derived-at-runtime/ I talk about ‘Getting rid of the ‘Ugly’ type definitions’. This means I do similar things to Generic services to decode the generic classes to make the signatures as simple as possible for the developer. Having said that I don’t think the interface definition is that simple, but it’s the best I can get for dependency injection to work properly.

Tomasz

I’ve read your articles about getting rid of repository pattern and I am very interested in this topic. I am a junior programmer trying to find my way of proper structuring backend of MVC app. Your approach (both with increasing criticism of using repository pattern with EF) seems the most interesting for me.

I’ve dug through SampleWebApp as well as the Complex version and from what I’ve learned I am about to use your GenericService in my app, but still have got one problem – actually I don’t see an easy way of linking business logic to your approach. Eventhough you have explained it in this post, it is still quite unclear form me how to use GenericService with business logic.

I understand that the library is a way to pass data from DataPersistance to Presentation. But how to deal with the business logic? In the layer picture of article linked above you mention a facade in the service layer. Am I right that the business layer (depending on specyfic usage) need to return DTOs compatible with GenericService as a result(of course if the call results in returning data). How to deal with business logic that returns no data but triggers some database operation – for example data processing thet results in adding new entities to the database, not necessarely posting anything to front ?

I would be grateful for brief description as there is not much about it over the Internet.

Your question is a good one and shows that I need to update this post to be a bit clearer. However I will give you a quick answer now as I am in a project and a full update will have to wait.

You have clearly grasped that I use a Service Layer to control access. Using a Service Layer is a common approach and I have found it, plus DTOs very useful. You might like to read my Simple Talk article that explains the structure a bit more – see https://www.simple-talk.com/dotnet/asp.net/using-entity-framework-with-an-existing-database–user-interface/

In my applications if the Presentation Layer needs a simple data access, often called CRUD actions, then it talks to my GenericServices library, with optional DTOs held in the Service Layer. If the Presentation Layer needs to do more complex actions, like say changing the status of an order based on some business logic, then it talks to my GenericActions library, again with optional DTOs held in the Service Layer. Both of these library are aimed at making the Service Layer much simpler to write.

The GenericActions library is private so I can’t show you how it works in detail. However it has a very similar interface to GenericServices, with DTOs etc, but it calls a business method, not a data access method. This means that the Presentation Layer uses identical logic for accessing the data directly (via GenericServices) or the Business Logic (via GenericActions). The only difference is the interface signature. That makes my life a lot simpler when developing applications.

Your last question shows you have thought this through, which is good. Yes, some Business Logic, say changing a status in the database, just returns a success/fail response. On the other hand some of my Business Logic might just be a ‘clever’ data access method which includes business logic that the Data Layer does not know about, which means it then returns data for the Presentation Layer to show.

Finally I would recommend a book which I found really useful on getting my head around the best architectural style for applications. It is a bit old and some of the libraries it uses are no longer the latest, but I think it gives a good overview of how to approach things. The free Ebook by Andrea Saltarello and Dino Esposito can be found here http://www.battleit.ee/public/Books/MSFT/Microsoft%20dotNET%20-%20Architecting%20Applications%20for%20the%20Enterprise.pdf

Thank you for your response. You confirmed my thgoughts about how it can be done. I am going to implement your approach in my app 😉

analytics book cover

The Analytics Setup Guidebook

Book content

Chapter 1. High-level Overview of an Analytics Setup

  • Start here - Introduction
  • A Simple Setup for People Just Starting Out
  • A Modern Analytics Stack
  • Our Biases of a Good Analytics Stack

Chapter 2. Centralizing Data

  • Consolidating Data from Sources Systems
  • Understanding The Data Warehouse
  • ELT vs ETL: What's The Big Deal?
  • Transforming Data in the ELT paradigm

Chapter 3. Data Modeling for Analytics

  • Data Modeling Layer and Concepts

Kimball's Dimensional Data Modeling

  • Modeling Example: A Real-world Use Case

Chapter 4. Using Data

  • Data Servicing — A Tale of Three Jobs
  • Navigating The Business Intelligence Tool Space
  • The Arc of Adoption

Chapter 5. Conclusion

Data modeling layer & concepts, a contemporary look at data modeling.

In this section we’re going to introduce data modeling from scratch. We shall approach this in a contemporary manner, which means that our presentation here is going to seem rather unusual to you if you’ve had prior experience with more classical techniques.

More specifically: if you have lots of experience with Kimball, Inmon or Data Vault-style data modeling, skim this section to familiarise yourself with the terms we introduce. We will tie the concepts back to the more classical approaches once we get to the next two sections.

If you don’t have any experience with data modeling, then buckle in. We’re going to take you on a ride. Let’s get started.

What is data modeling and why is it needed?

To best understand what data modeling is, let’s imagine that your company runs a homestay booking site, and that it has data stored in a production database.

When the CEO has a question to ask about data, she goes to the data analyst and asks: “Hey, Daniel can you help me get the sales commissions numbers for bookings in this region?”

Daniel listens to the CEO’s request, goes to his computer, and comes back with the data, sometimes in the form of a short written note, other times with the data presented in an Excel file.

So here’s our question: why can’t the CEO do it themselves? Wouldn’t the ideal situation be that the CEO opens up some exploration tool that’s linked directly to the production database and helps herself to the data? Why does she have to go through the data analyst to get it for her?

“She doesn’t know how to do it”, you might say, or “This is serious technical stuff”. These are common responses that you might get when you pose this question.

But there’s something else that’s going on here.

The CEO (or any other business user, for that matter) thinks in business terms, using business logic. Your actual data, on the other hand, is stored in a different format. It follows different rules — often rules imposed by the implementation of the application.

The CEO can’t translate her mental model of the business into code in order to run the numbers. She doesn’t know how the data is organized. But Daniel does.

For example: when asking about sales commissions, the CEO will think “sales commissions is 5% of closed deals”. However, the data analyst will think “closed deals are stored in table closed_deals , so I need to take the amount column and multiply that with months to figure out the final amount; oh, and I need to check the payment_received column to make sure that only the received payment is counted” .

Here, Daniel the data analyst simply serves as a “data translator” :

  • He receives a data question in business English
  • He figures out where the corresponding data lies in his data warehouse
  • He then translates the business question into corresponding data logic , and expresses this logic in the form of a data query (usually SQL).
  • He runs the query, get the results to Excel, formats it, and then sends it over to the CEO.

Essentially, the data analyst knows the mapping between business logic to data logic . That’s why he is able to help the CEO with her data questions.

Data Analyst

This process works fine for some companies. But it will not scale up beyond a few people, and is an incredibly inefficient way to do things. Why? Well:

  • Your data analyst Daniel is now a bottleneck. Every small change needs to go through him.
  • What if Daniel goes on leave? What if Daniel leaves the company? What if Daniel forgets how a certain piece of business logic is implemented?
  • Every time the CEO wants something, she needs to wait hours (or even days) for Daniel to crunch the numbers and get back to her.
  • At one point, Daniel might be too busy crunching out numbers for different business stakeholders, instead of focusing his time on more valuable, long-term impact work.

So what do we need to do here?

We need to offload the mapping knowledge inside Daniel’s head into some system, so that anyone can understand it. We need to externalize it, so that it doesn’t just live in Daniel’s head.

The Data Modeling Layer

Earlier in this book, we introduced you to the idea that we should extract data into a data warehouse first, before doing transformations. We mentioned that this is commonly known as the ‘ELT’ paradigm.

What we want to do now is to perform some series of transformations to offload the mapping in Daniel’s head to something that is persisted in a data warehouse. Again, all of these transformations are to be performed within the data warehouse, as per the ELT paradigm.

This process of mapping raw data to a format that can be easily understood by business users is known as ‘data modeling’. There are other reasons to do data modeling, of course. Performance is one of them, as is explorability. But at its most basic level, data modeling is about taking raw data and transforming it into a form that is useful for business measurement.

The contemporary approach to doing data modeling is to orchestrate transformations within the data warehouse, via a tool that sits on top of the data warehouse . This stands in contrast to ETL tools in the past, which usually exist as pipelines external to the data warehouse.

Data modeling layer

These tools include such tools like Holistics, dbt, dataform and Looker. These tools share a couple of similar characteristics:

  • They connect to your data warehouse.
  • They treat the modeling process as the act of transforming data from old tables to new ones within the data warehouse.
  • They generate SQL behind the scenes to execute such transformations.
  • They allow users to annotate, manage, and track changes to data models over time.
  • They allow users to trace the lineage of data transformations within a single tool.

There isn’t a good name for such tools right now. For the sake of convenience, we will call them ‘data modeling layer’ tools. Conceptually, they present a ‘data modeling layer’ to the analytics department.

A data modeling layer is a system that contains the mapping between business logic and underlying data storage rules of your business. It exists primarily in the ELT paradigm, where data is loaded into the data warehouse first before being transformed.

In this context, data modeling is the process of building and maintaining this layer.

Usually, the data modeling layer will later be connected to some visualization tool or business intelligence layer. Non-technical users should be able to log in, interact with some user interface, and get the analytics they need, without the requirement to talk to anyone technical.

With a proper, well-maintained data modeling layer, everyone is happy:

  • The CEO can just log in to the BI application, ask questions and get the right numbers that she needs, without waiting for the data analyst. In other words, business users can now do self-service analytics.
  • The data analyst’s job is now focused on maintaining the data pipeline and modeling layer, without being bombarded by adhoc data requests.
  • The entire company has a well-documented layer of data knowledge. Even if the data analyst is busy or leaves the company, this knowledge is properly annotated and organized, and not at risk of being lost.

Abstraction layer

Now that we know what data modeling is at a high level and why it’s important, let’s talk about specific concepts that exist in the data modeling layer paradigm.

Data Modeling Layer Concepts

Let’s return to the homestay booking example above. We shall use this as an overarching example to introduce data modeling layer concepts to you.

These are the basic database tables that you pulled into your data warehouse.

Database tables

Now, let’s look at a few modeling operations that you can apply to the above data.

We’ll be using Holistics for the examples below. That said, these concepts map pretty well across any data modeling layer-type tool in the market. (We’ll tell you if we’re introducing an idea that is specific to Holistics, with no clear external analogs).

Concept: Data Model

When manipulating data in a data modeling layer, it’s common not to deal with the underlying data table directly, but to instead create an abstract object above it for ease of manipulation.

Data model

This is called a data model.

A data model is an abstract view on top of a physical database table that you may manipulate without directly affecting the underlying data. Most data modeling layers allow you to store additional metadata that may enrich the underlying data in the data table.

The most common types of metadata at the level of a data model are textual descriptions, calculated dimensions that capture some business logic, and relationship mappings between a model and some other model (or table). Data modeling layers often also include housekeeping metadata alongside the data model, such as a full history of user accounts who have modified the model, when that model was first created and last modified, when the underlying data was last refreshed, and so on.

While database tables hold data, data models often contain metadata to provide extra context for that data.

A data table is managed by the database, and a data model is managed by the data modeling layer that you use.

Here’s a quick comparison between the two:

Data Table:

  • Is ‘physical’, lives in the analytical database
  • Store actual data records

Data Model:

  • Is an abstract object, managed by the data modeling layer
  • Stores metadata (description, business logic, relationship mapping)
  • Usually sits above a data table
  • Is usually created via a SELECT statement from the data table.

By connecting a modeling layer to your analytics database, you can “model up” your database tables so that you can add textual descriptions, or metadata. This is what it looks like in Holistics:

Data modeling

In the Holistics interface above, we take a table in our data warehouse named homestay.listings and create a data model named homestay_listings . This model is ‘abstract’, in the sense that it lives only within the data modeling layer.

Similar flows exist in dbt, dataform and Looker.

Concept: Relationship mapping

A relationship mapping is a foreign relationship between two data models.

This relationship is analogous to the foreign key concept in relational databases. In this context, however, we are creating relationships between two data models instead of tables — that is, relationships between two abstract ‘views’ of data that don’t actually exist in the data warehouse below.

Relationship mapping

Defining a model’s relationships is like defining JOINs between the data tables.

This is useful because you may want to create models that derive from other models, instead of deriving from just underlying database tables.

Concept: Custom Field Logic

Remember earlier that we had a few pieces of business logic that the CEO might want to check? For instance, one metric the CEO might be particularly interested in is the number of guests per booking. This way, she can have a good idea of the inventory matchup between available rooms and groups of guests. Notice how a measure of the number of guests might not exist in the underlying table. Instead, we’re going to define it as a combination of table dimensions, but within the data modeling layer.

In Holistics, we open up the homestay_bookings model and define our custom dimensions and measures, like so:

Custom dimension measure

We have defined two custom fields here. The first is the sum of nights stayed from a successful booking (that is, a booking that has been seen to check out). If the booking has reached the ‘checked out’ state, then the nights are counted. Otherwise, it returns 0.

The second is a calculated field that returns the total number of guests per booking. This latter field is a simple sum, because the homestay.bookings table stores the number of children, babies, and adults as separate numbers. In our homestay_bookings model, we simply define the total number of guests as the sum of all three numbers.

We call these measures ‘custom fields’ in Holistics; though the idea is more important than the specific name we’ve used. The idea is this: data modeling layers allow you to create calculated fields that are combinations of other fields within the model. Similar concepts exist in other modeling BI tools — the point is that you want to be able to augment existing dimensions in the underlying tables.

Concept: Models Built On Top of Other Models

At this stage, we’ve merely demonstrated that data models allow you to annotate and enrich existing tables in your data warehouse. But what if you want to transform your data into a new set of tables? Imagine, for instance, that you want to take the data within homestay.listings and turn it into a star schema. In the past, you might have done this by asking a data engineer to set up a new ETL pipeline. With a data modeling layer tool, however, you may do this within the same user interface.

Below, we’ve created a new model that is derived from the homestay_listings data model (not the table!). This model is called bookings_revenue , and it combines fields from two different models — the homestay_listings model and the homestay_bookings models — to calculate things like gmv and host_revenue .

Modeling example

Notice the conceptual leap that’s just happened. homestay.bookings and homestay.listings are two tables in our data warehouse. We’ve created two models respectively above them: homestay_bookings and homestay_listings . As we’ve mentioned previously, these models allow us to annotate or create new derived fields without touching the tables themselves.

We have then taken the two models , and created a new transformed model on top of them.

Transformed data model

This is powerful for two reasons. First, all of this has happened via SQL. We do not need to wait for data engineering to set up a new transformation pipeline; we can simply ask an analyst to model the data within the Holistics data modeling layer, by writing the following SQL:

Join models

As you can see, our new bookings_revenue model is simply a SELECT statement that JOINS two models . (Emphasis added).

Second, the fact that our model exists as a simple join means that our bookings_revenue model will be updated whenever the two underlying models (or their underlying tables) are updated!

Again, the idea here is more important than the particular implementation we’ve shown you. You will find similar flows in other data modeling layer tools (like Dataform, for instance).

Concept: Model Persistence (equivalent to materialized view)

Once you understand that it’s possible to create new models from other models by writing SQL, the next step is to ask: is it possible to persist such transformations?

The answer is yes, of course!

Model persistence

While data models are normally ‘views’ (or SELECT statements) on top of physical tables, nearly all data modeling layers allow you to persist these as new tables within the data warehouse. This is what the Holistics persistence menu looks like, for instance:

Persistence menu

Here, Holistics offers to update these models at periodic times. In our example above, we can choose to persist bookings_revenue to our data warehouse, and let Holistics update the model every day at 7 am (or whatever other time intervals we wish).

Persistence is useful for performance reasons; in this case, our revenue reporting may run on top of the bookings_revenue persisted table, instead of the abstract model itself.

Putting things together

Let’s put the above concepts together in a single diagram, as a way to wrap things up.

Wrap up

Notice three things:

  • homestay_listings is a base model that is derived from homestay_bookings and homestay_hosts .
  • bookings_revenue is a ‘transformed’ model that is drawn from homestay_bookings and homestay_listings . Note how it contains custom fields that are basically calculations of multiple fields that exist within its underlying models.
  • Similarly, bookings_profit is a transformed model that is taken from bookings_revenue .

This dependency diagram of models is pretty representative of the sort of work analysts at Holistics do on a day-to-day basis. The job of data analytics is essentially a process of modeling raw tables into base models, and then modeling base models into transformed models.

Our analysts do this until they have a tapestry of data models that represent everything our business people would ever want to know about our company. Then, creating a report simply becomes an issue of picking the right models to present to the business.

What do business users get in the end?

Remember at the beginning of this section, we said that with a data modeling layer, the CEO can extract meaningful numbers by herself without having to bother the data analyst? Well, we weren’t lying.

With a SQL-based data modeling BI tool (like Holistics or Looker), the CEO can now use a UI to help herself to the data she needs, based on the metrics, descriptions, and relationships we have defined above.

self-service data exploration

Example of self-service data exploration UI that CEO can play around.

What happens behind the scenes is this: the CEO’s selection will be translated into a corresponding SQL query (thanks to the modeling layer), and this query will be sent to the analytical database. The retrieved results will then be displayed for the CEO to view.

excuted query

So what have we covered? We’ve looked at data modeling in the ELT paradigm. The modern approach to data modeling in this paradigm is to use what we call a ‘data modeling layer’, though this is a name that we’ve adopted out of convenience. Such tools include Dataform, dbt, Looker, and Holistics itself.

We then discussed several ideas that exist within this approach to data modeling:

  • We talked about how data models are ‘abstract views’ on top of your data, within the context of a ‘data modeling layer’.
  • We talked about how such data modeling layer-type tools allowed users to enrich models with metadata, and how most modeling layers added useful housekeeping data like user modifications, freshness of the underlying data, and so on.
  • We discussed two useful features of data models: custom field logic and relationship mapping.
  • We then talked about how data models may be built on top of other models.
  • Finally, we talked about how such derived models may be persisted, just like materialized views in a more traditional relational database system.

In our next section, we shall talk about how this approach to data modeling works when it is combined with the classical method of dimensional data modeling.

8                       Business Layer

Business Layer elements are used to model the operational organization of an enterprise in a technology-independent manner, whereas strategy elements (Chapter 7 ) are used to model the strategic direction and choices of the enterprise.

8.1                  Business Layer Metamodel

Figure 52 gives an overview of the Business Layer elements and their relationships. “Business Internal Active Structure Element”, “Business Internal Behavior Element”, and “Business Passive Structure Element” are abstract elements; only their specializations (as defined in the following sections) are instantiated in models.

what is a business layer model

Figure 52 : Business Layer Metamodel

Note:      This figure does not show all permitted relationships; every element in the language can have composition, aggregation, and specialization relationships with elements of the same type. Furthermore, there are indirect relationships that can be derived, as explained in Section 5.7 .

8.2                  Active Structure Elements

The active structure aspect of the Business Layer refers to the static structure of an organization, in terms of the entities that make up the organization and their relationships. The active entities are the subjects (e.g., business actors or business roles) that perform behavior such as business processes or functions (capabilities). Business actors may be individual persons (e.g., customers or employees), but also groups of people (organization units) and resources that have a permanent (or at least long-term) status within the organizations. Typical examples of the latter are a department and a business unit.

Architectural descriptions focus on structure, which means that the inter-relationships of entities within an organization play an important role. To make this explicit, the element of business collaboration has been introduced.

The element of business interface is introduced to explicitly model the (logical or physical) places or channels where the services that a role offers to the environment can be accessed. The same service may be offered on a number of different interfaces; e.g., by mail, by telephone, or through the Internet. In contrast to application modeling, it is uncommon in current Business Layer modeling approaches to recognize the business interface element.

In the Business Layer, three types of internal active structure element are defined: business actor , business role , and business collaboration .

what is a business layer model

Figure 53 : Business Internal Active Structure Elements

Note:      This figure does not show all permitted relationships; every element in the language can have composition, aggregation, and specialization relationships with elements of the same type. Furthermore, there are indirect relationships that can be derived, as explained in Section 5.7 . The full specification of permitted relationships can be found in Appendix B .

8.2.1               Business Actor

A business actor  represents a business entity that is capable of performing behavior.

A business actor is a business entity as opposed to a technical entity; i.e., it belongs to the Business Layer. Actors may, however, include entities outside the actual organization; e.g., customers and partners. A business actor can represent such business entities at different levels of detail and may correspond to both an actor and an organizational unit in the TOGAF framework [ 4 ]. Examples of business actors are humans, departments, and business units.

A business actor may be assigned to one or more business roles. It can then perform the behavior to which these business roles are assigned. A business actor can be aggregated in a location. The name of a business actor should preferably be a noun. Business actors may be specific individuals or organizations; e.g., “John Smith” or “ABC Corporation”, or they may be generic; e.g., “customer” or “supplier”.

Figure 54 : Business Actor Notation

8.2.2               Business Role

A business role  represents the responsibility for performing specific behavior, to which an actor can be assigned, or the part an actor plays in a particular action or event.

Business roles with certain responsibilities or skills are assigned to business processes or business functions. A business actor that is assigned to a business role is responsible for ensuring that the corresponding behavior is carried out, either by performing it or by delegating and managing its performance. In addition to the relation of a business role with behavior, a business role is also useful in a (structural) organizational sense; for instance, in the division of labor within an organization.

A business role may be assigned to one or more business processes or business functions, while a business actor may be assigned to one or more business roles. A business interface or an application interface may serve a business role, while a business interface may be part of a business role. The name of a business role should preferably be a noun.

what is a business layer model

Figure 55 : Business Role Notation

ArchiMate modelers may represent generic organizational entities that perform behavior as either business actors or business roles. For example, the business actor “Supplier” depicts an organizational entity, while the business role “Supplier” depicts a responsibility. Specific or generic business actors can be assigned to carry responsibilities depicted as business roles. For example, the specific business actor “ABC Corporation” or the generic business actor “Business Partner” can be assigned to the “Supplier” business role.

8.2.3               Business Collaboration

A business collaboration  represents an aggregate of two or more business internal active structure elements that work together to perform collective behavior.

A business process or function may be interpreted as the internal behavior of a single business role. In some cases, behavior is the collective effort of more than one business role; in fact, a collaboration of two or more business roles results in collective behavior which may be more than simply the sum of the behavior of the separate roles. Business collaborations represent this collective effort. Business interactions can be used to describe the internal behavior that takes place within business collaboration. A business collaboration is a (possibly temporary) collection of business roles, actors, or other collaborations within an organization which perform collaborative behavior (interactions). Unlike a department, a business collaboration need not have an official (permanent) status within the organization; it is specifically aimed at a specific interaction or set of interactions between roles. It is especially useful in modeling Business-to-Business (B2B) interactions between different organizations such as provider networks, and also for describing social networks.

A business collaboration may aggregate a number of business roles, actors, or other collaborations and may be assigned to one or more business interactions or other business internal behavior elements. A business interface or an application interface may serve a business collaboration, while a business collaboration may have business interfaces (through composition, and also through aggregation via derived relationships). The name of a business collaboration should preferably be a noun. It is also rather common to leave a business collaboration unnamed.

what is a business layer model

Figure 56 : Business Collaboration Notation

8.2.4               Business Interface

A business interface  represents a point of access where a business service is made available to the environment.

A business interface exposes the functionality of a business service to other business roles or actors. It is often referred to as a channel (telephone, Internet, local office, etc.). The same business service may be exposed through different interfaces.

A business interface may be part of a business role or actor through a composition relationship, and a business interface may serve a business role. A business interface may be assigned to one or more business services, which means that these services are exposed by the interface. The name of a business interface should preferably be a noun.

Figure 57 : Business Interface Notation

8.2.5               Example

The “ArchiSurance Contact Center”, modeled as a business actor, is composed of three employees, also modeled as business actors: “Greg”, “Joan”, and “Larry”. The “ArchiSurance Contact Center” has three business interfaces to serve customers: “Phone”, “E-mail”, and “Web Chat”. Greg fulfills the business role of “Travel Insurance Claim Analyst”, Joan fulfills the business role of “Home Insurance Product Specialist”, and Larry fulfills the business role of “Customer Service Representative”. The former two business roles are specializations of a business role “Specialist”. “High-Risk Claims Adjudication” is a business collaboration of two business roles: “Specialist” and “Customer Service Representative”.

what is a business layer model

Example 23 : Business Active Structure Elements

8.3                  Behavior Elements

Based on service-orientation, a crucial design decision for the behavioral part of the ArchiMate metamodel is the distinction between “external” and “internal” behavior of an organization.

The externally visible behavior is modeled by the element business service . A business service represents a coherent piece of functionality that offers added value to the environment, independent of the way this functionality is realized internally. A distinction can be made between “external” business services, offered to external customers, and “internal” business services, offering supporting functionality to processes or functions within the organization.

Several types of internal behavior elements that can realize a service are distinguished. Although the distinction between the two is not always sharp, it is often useful to distinguish a process view and a function view on behavior; two elements associated with these views, business process and business function , are defined. Both elements can be used to group more detailed business processes/functions but based on different grouping criteria. A business process represents a workflow consisting of smaller processes/functions, with one or more clear starting points and leading to some result. It is sometimes described as “customer to customer”, where this customer may also be an internal customer, in the case of sub-processes within an organization. The goal of such a business process is to “satisfy or delight the customer” [ 10 ]. A business function offers functionality that may be useful for one or more business processes. It groups behavior based on, for example, required skills, resources, (application) support, etc. Typically, the business processes of an organization are defined based on the products and services that the organization offers, while the business functions are the basis for, for example, the assignment of resources to tasks and the application support.

A business interaction is a unit of behavior similar to a business process or function, but which is performed in a collaboration of two or more roles within the organization. Unlike the interaction concept in AMBER [ 9 ], which is an atomic unit of collaborative behavior, the ArchiMate business interaction can be decomposed into smaller interactions. Although interactions are external behavior from the perspective of the roles participating in the collaboration, the behavior is internal to the collaboration as a whole. Similar to processes or functions, the result of a business interaction can be made available to the environment through a business service.

A business event is something that happens (externally) and may influence business processes, functions, or interactions. The business event element is similar to BPMN event elements, to the trigger element in AMBER [ 9 ], and the initial state and final state elements in UML activity diagrams. However, the ArchiMate business event is more generally applicable in the sense that it can also be used to model other types of events, in addition to triggers.

In the Business Layer, three types of internal behavior element are defined: business process , business function , and business interaction .

what is a business layer model

Figure 58 : Business Internal Behavior Elements

8.3.1               Business Process

A business process  represents a sequence of business behaviors that achieves a specific result such as a defined set of products or business services.

A business process describes the internal behavior performed by a business role that is required to produce a set of products and services. For a consumer, the products and services are relevant and the required behavior is merely a black box, hence the designation “internal”.

A complex business process may be an aggregation of other, finer-grained processes. To each of these, finer-grained roles may be assigned.

There is a potential many-to-many relationship between business processes and business functions. Informally speaking, processes describe some kind of “flow” of activities, whereas functions group activities according to required skills, knowledge, resources, etc.

A business process may be triggered by, or trigger, any other business behavior element (e.g., business event, business process, business function, or business interaction). A business process may access business objects. A business process may realize one or more business services and may use (internal) business services or application services. A business role may be assigned to a business process to perform this process manually. An automated business process can be realized by an application process. The name of a business process should clearly indicate a predefined sequence of actions using a verb or verb-noun combination and may include the word “process”. Examples are “adjudicate claim”, “employee on-boarding”, “approval process”, or “financial reporting”.

In an ArchiMate model, the existence of business processes is depicted. High-level business, end-to-end processes, macro flows, and workflows can all be expressed with the same business process element in the ArchiMate language. It does not, however, list the flow of activities in detail. This is typically done during business process modeling, where a business process can be expanded using a business process design language; e.g., BPMN [ 12 ].

what is a business layer model

Figure 59 : Business Process Notation

8.3.2               Business Function

A business function  represents a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization.

Just like a business process, a business function also describes internal behavior performed by a business role. However, while a business process groups behavior based on a sequence or flow of activities that is needed to realize a product or service, a business function typically groups behavior based on required business resources, skills, competencies, knowledge, etc.

There is a potential many-to-many relation between business processes and business functions. Complex processes in general involve activities that offer various functions. In this sense, a business process forms a string of business functions. In general, a business function delivers added value from a business point of view. Organizational units or applications may coincide with business functions due to their specific grouping of business activities.

A business function may be triggered by, or trigger, any other business behavior element (business event, business process, business function, or business interaction). A business function may access business objects. A business function may realize one or more business services and may be served by business, application, or technology services. A business role may be assigned to a business function. The name of a business function should clearly indicate a well-defined behavior. Examples are customer management, claims administration, member services, recycling, or payment processing.

Figure 60 : Business Function Notation

8.3.3               Business Interaction

A business interaction  represents a unit of collective business behavior performed by (a collaboration of) two or more business actors, business roles, or business collaborations.

A business interaction is similar to a business process/function, but while a process/function may be performed by a single role, an interaction is performed by a collaboration of multiple roles. The roles in the collaboration share the responsibility for performing the interaction.

A business interaction may be triggered by, or trigger, any other business behavior element (business event, business process, business function, or business interaction). A business interaction may access business objects. A business interaction may realize one or more business services and may use (internal) business services or application services. A business collaboration or two or more business actors or roles may be assigned to a business interaction. The name of a business interaction should preferably be a verb in the simple present tense.

Figure 61 : Business Interaction Notation

8.3.4               Business Event

A business event  represents an organizational state change.

Business processes and other business behavior may be triggered or interrupted by a business event. Also, business processes may raise events that trigger other business processes, functions, or interactions. Unlike business processes, functions, and interactions, a business event is instantaneous: it does not have duration. Events may originate from the environment of the organization (e.g., from a customer), but also internal events may occur generated by, for example, other processes within the organization.

A business event may have a time attribute that denotes the moment or moments at which the event happens. For example, this can be used to model time schedules; e.g., to model an event that triggers a recurring business process to execute every first Monday of the month.

A business event may trigger or be triggered (raised) by a business process, business function, or business interaction. A business event may access a business object and may be composed of other business events. The name of a business event should preferably be a verb in the perfect tense; e.g., “claim received”.

Figure 62 : Business Event Notation

8.3.5               Business Service

A business service  represents explicitly defined behavior that a business role, business actor, or business collaboration exposes to its environment.

A business service exposes the functionality of business roles or collaborations to their environment. This functionality is accessed through one or more business interfaces.

A business service should provide a unit of behavior that is meaningful from the point of view of the environment. It has a purpose, which states this utility. The environment includes the (behavior of) users from outside as well as inside the organization. Business services can be external, customer-facing services (e.g., a travel insurance service) or internal support services (e.g., a resource management service).

A business service is associated with a value. A business service may serve a business process, business function, or business interaction. A business process, business function, or business interaction may realize a business service. A business interface may be assigned to a business service. A business service may access business objects. The name of a business service should preferably be a verb ending with “-ing”; e.g., transaction processing. Also, a name explicitly containing the word “service” may be used.

Figure 63 : Business Service Notation

8.3.6               Example

“Claims Administration” is a business function that is composed of a number of business processes and a business interaction. This business function realizes a “Claims Processing” business service. A business event “Claim Filed” triggers the first business process “Accept Claim”, which in turn triggers a business process “Assign Claim”. Depending on the type of claim, either the business process “Adjudicate Standard Claim” or the business interaction “Adjudicate High-Risk Claim” is performed. Adjudication of high-risk claims is a business interaction because, according to the company policy, two people should always be involved in this activity to minimize the risk of fraud. After adjudication, the business processes “Notify Customer” and “Pay Claim” are performed in parallel, and when both have finished, business process “Close Claim” is triggered.

what is a business layer model

Example 24 : Business Behavior Elements

8.4                  Passive Structure Elements

The passive structure aspect of the Business Layer contains the passive structure elements (business objects) that are manipulated by behavior, such as business processes or functions. The passive entities represent the important concepts in which the business thinks about a domain.

In the Business Layer, there are two main types of passive structure elements: business object and representation . Furthermore, a contract, used in the context of a product, is a specialization of a business object.

what is a business layer model

Figure 64 : Business Passive Structure Elements

8.4.1               Business Object

A business object  represents a concept used within a particular business domain.

As explained in Section 3.6 , the ArchiMate language in general focuses on the modeling of types, not instances, since this is the most relevant at the Enterprise Architecture level of description. Hence a business object typically models an object type ( cf. a UML class) of which multiple instances may exist in operations. Only occasionally, business objects represent actual instances of information produced and consumed by behavior elements such as business processes. This is in particular the case for singleton types; i.e., types that have only one instance.

A wide variety of types of business objects can be defined. Business objects are passive in the sense that they do not trigger or perform processes. A business object could be used to represent information assets that are relevant from a business point of view and can be realized by data objects.

Business objects may be accessed (e.g., in the case of information objects, they may be created, read, or written) by a business process, function, business interaction, business event, or business service. A business object may have association, specialization, aggregation, or composition relationships with other business objects. A business object may be realized by a representation or by a data object (or both). The name of a business object should preferably be a noun.

what is a business layer model

Figure 65 : Business Object Notation

8.4.2               Contract

A contract  represents a formal or informal specification of an agreement between a provider and a consumer that specifies the rights and obligations associated with a product and establishes functional and non-functional parameters for interaction.

The contract element may be used to model a contract in the legal sense, but also a more informal agreement associated with a product. It may also be or include an SLA describing an agreement about the functionality and quality of the services that are part of a product. A contract is a specialization of a business object.

The relationships that apply to a business object also apply to a contract. In addition, a contract may have an aggregation relationship with a product. The name of a contract is preferably a noun.

Figure 66 : Contract Notation

8.4.3               Representation

A representation  represents a perceptible form of the information carried by a business object.

Representations (for example, messages or documents) are the perceptible carriers of information that are related to business objects. If relevant, representations can be classified in various ways; for example, in terms of medium (electronic, paper, audio, etc.) or format (HTML, ASCII, PDF, RTF, etc.). A single business object can have a number of different representations. Also, a single representation can realize one or more specific business objects.

A meaning can be associated with a representation that carries this meaning. The name of a representation is preferably a noun.

Figure 67 : Representation Notation

8.4.4               Example

The business object “Claim” may be realized by either of the following three physical representations (in different stages of the claims administration process): “Submission Form”, “Claim File Summary”, or “Claim Letter”. All of these representations refer to a representation “Policy Summary”, which realizes a contract “Insurance Policy”.

Example 25 : Business Passive Structure Elements

8.5                  Composite Elements

The Business Layer contains one composite element: product . This aggregates or composes services and passive structure elements across the layers of the ArchiMate core language.

Figure 68 shows the applicable part of the metamodel. This crosses layers, as also described in Chapter 12 .

Figure 68 : Product Metamodel

8.5.1               Product

A product  represents a coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.

This definition covers both intangible, services-based, or information products that are common in information-intensive organizations, and tangible, physical products. A financial or information product consists of a collection of services, and a contract that specifies the characteristics, rights, and requirements associated with the product. “Buying” a product gives the customer the right to use the associated services.

Generally, the product element is used to specify a product type . The number of product types in an organization is typically relatively stable compared to, for example, the processes that realize or support the products. “Buying” is usually one of the services associated with a product, which results in a new instance of that product (belonging to a specific customer). Similarly, there may be services to modify or destroy a product.

A product may aggregate or compose business services, application services, and technology services, business objects, data objects, and technology objects, as well as a contract. Hence a product may aggregate or compose elements from other layers than the Business Layer.

A value may be associated with a product. The name of a product is usually the name which is used in the communication with customers, or possibly a more generic noun (e.g., “travel insurance”).

Figure 69 : Product Notation

8.5.2               Example

A product “Insurance” consists of a contract “Insurance Policy” and a business service “Customer Service”, which aggregates four other business services: “Application”, “Renewal”, “Claims Processing”, and “Appeal”. An “Auto Insurance” product is a specialization of the generic “Insurance” product, with an additional business service “Drive Well and Save”, and accompanying contract “Drive Well and Save Agreement”.

what is a business layer model

Example 26 : Business Composite Element: Product

8.6                  Summary of Business Layer Elements

Table 6 gives an overview of the Business Layer elements, with their definitions.

Table 6 : Business Layer Elements

Downloads of the ArchiMate documentation are available under license from the Download link within the ArchiMate information web site . The license is free to any organization wishing to use ArchiMate documentation entirely for internal purposes. A book is also available from The Open Group Library as document C197 .

 FourWeekMBA

The Leading Source of Insights On Business Model Strategy & Tech Business Models

business-logic-layer

Business Logic Layer And Why It Matters To Understand Blockchain Business Models

In programming, the Business Logic Layer (BLL) serves as an intermediary for data exchange between the presentation layer and the Data Access Layer (DAL). The Business Logic Layer handles the business rules, calculations, and logic within an application which dictate how it behaves. That is, the BLL determines how data from the database is used and what it can and cannot do within the application itself. 

Table of Contents

Understanding a business logic layer

The business logic layer handles the business rules, calculations, and logic within an application which dictate how it behaves. That is, the BLL determines how data from the database is used and what it can and cannot do within the application itself. 

In this way, the business logic layer manages communication between the database and the presentation layer – sometimes referred to as the end-user interface. It forms part of the multitier architecture of software engineering where various functions are physically separated.

Separation typically involves functions assigned to one of three layers:

  • User interface (UI) layer – where all presentation and user interaction occurs. Data is displayed to the user. The user sends and also receives data.
  • Business logic layer (BLL) – as we have noted, the BLL deals with application processing and coordinates the flow of data between the UI and DAL.
  • Data access layer (DAL) – or the layer where data management takes place. In most cases, this is via a web service or database.

Collectively, each of the three layers plays an integral role in many web applications. Consider the example of an insurance website that features an application where consumers can view their insurance policies. 

The consumer’s browser interacts with the application’s user interface layer code, with customer policy data held in the data access layer. The BLL is the most important component since it contains any important calculations or business logic and ultimately, determines whether the consumer is entitled to obtain insurance cover.

Differentiating between business logic and business rules

Business logic sets out how business objects interact with each other and enforces how these objects are updated and accessed. Logic decides how data is transformed, calculated, and sent to workflows, which are the ordered tasks one participant (user, software) sends to another.

Business rules, on the other hand, are formal expressions of “real-world” business policy, such as those relating to loans, accounts, and itineraries. 

To explain the difference more succinctly, it can be helpful to remember that any procedure or process falls under the business logic banner. Any factor that is neither of these can be considered a business rule. 

When a consumer visits an eCommerce website, for example, business logic defines a workflow where the consumer can add a product to their cart, enter their postal address, provide their credit card details, and land on a confirmation page. An example of a business rule in this process may describe a particular method for communicating with the VisaNet electronic payments network .

Defining a business logic layer

Both the UI and DAL are relatively easy to define and understand. However, there is less clarity on what constitutes a BLL. As a result, many businesses (including Apple and Microsoft) exclude the BLL from their applications entirely and have UI code communicate directly with the DAL.

In coding, this leads to what is colloquially called the “Fat Controller”. This describes a controller with domain logic servicing too many requests. In turn, controller logic becomes overly complex and too dependent on domain concepts. Ultimately, this complexity makes code maintenance difficult. 

A better option is to design the application to support multiple different user interfaces. Code that is common to each user interface then becomes the business logic layer.

Generally speaking, this code is any which deals with the following:

  • Persisting data (to the DAL).
  • Displaying data (to the UI layer).
  • Accessing data (from the DAL).
  • Making logical decisions.
  • Performing calculations.
  • Maintaining application state.
  • Coordinating workflow.
  • Processing commands (from the UI layer).

Used properly, the BLL centralizes as much common logic as possible and is not tied to a particular UI. This enables the application to support any number of user interfaces and minimizes instances of code duplication. 

It’s also worth noting that the code in the UI layer must necessarily shrink as it grows in the BLL. This concept is central to the “Thin Controller” theory. As the BLL grows and starts to become bloated, the layer can be separated further by moving from a three-tier to an n -tier architecture.

Benefits of business logic layers

Business logic layers are a recommended software engineering convention. Together with the user interface and data access layers, this multitier architecture has important implications for code reusability and modular design . 

To that end, there are several benefits to adopting the compartmentalized approach:

  • Code maintenance – as we touched on briefly in the previous section, multitier architecture makes code maintenance much easier. When a business requirement changes, the associated business logical layer is often the only component that requires code to be altered. By the same token, it can be very difficult to determine where in the application a code change should be made if there is no compartmentalization whatsoever. 
  • Application releases – another benefit of the business logic layer and multitiered architecture is the ease with which application releases can be rolled out. It stands to reason that if the BLL was the only layer to be updated, then it is the only one that should be used in the production environment. That is, the user interface layer and data access layer can be left alone and remain unaltered.
  • Ease of learning – development teams may also benefit from the BLL and multitier architecture approach. Individual employees need only specialize in presentation development, data, or business logic skills to more rapidly learn their specific part of the application. This also has positive implications for efficiency. Since each layer can be worked on at the same time, the development timeframe becomes shorter.

Key takeaways:

  • A business logic layer serves as an intermediary for data exchange between the data access layer (DAL) and the user interface (UI) layer.
  • Finding it too difficult to define, many businesses omit the business logic layer completely. With the DAL communicating directly with the UI, code becomes overly complex and maintenance problematic.
  • A business logic layer allows developers to design applications that support multiple user interfaces. This minimizes the chances of needless code duplication.

Read Next:  Proof-of-stake ,  Proof-of-work ,  Bitcoin ,  Ethereum ,  Blockchain .

Related Blockchain Business Frameworks

web3

Blockchain Protocol

blockchain-protocol

Merkle Tree

merkle-tree

Nothing-at-stake

nothing-at-stake-problem

Proof of Work

proof-of-work

Application Binary Interface

application-binary-interface

Proof of Stake

proof-of-stake

Proof of Work vs. Proof of Stake

proof-of-work-vs-proof-of-stake

Proof of Activity

proof-of-activity

Blockchain Economics

blockchain-economics

Blockchain Business Model Framework

blockchain-business-models

Smart Contracts

smart-contracts

Non-Fungible Tokens

non-fungible-tokens

Decentralized Finance

decentralized-finance-defi

History of Bitcoin

history-of-bitcoin

Ethereum Flywheel

blockchain-flywheel

Decentralized Exchange

decentralized-exchange-platforms

  • Business Models
  • Business Strategy
  • Business Development
  • Digital Business Models
  • Distribution Channels
  • Marketing Strategy
  • Platform Business Models
  • Revenue Models
  • Tech Business Models
  • Blockchain Business Models Framework

More Resources

web3

About The Author

' src=

Gennaro Cuofano

Discover more from fourweekmba.

Subscribe now to keep reading and get access to the full archive.

Type your email…

Continue reading

  • 70+ Business Models
  • Airbnb Business Model
  • Amazon Business Model
  • Apple Business Model
  • Google Business Model
  • Facebook [Meta] Business Model
  • Microsoft Business Model
  • Netflix Business Model
  • Uber Business Model

You are using an outdated browser (IE 8 or before). For a better user experience, we recommend upgrading your browser today or installing Google Chrome Frame

FREE ArchiMate Articles, Tutorials, Samples, Tool & More

Secondary navigation menu, what is business layer in archimate learn by example.

ArchiSurance – Business Layer Example

what is a business layer model

In this example, (1) Client and (2) ArchiSurance are business actors, the active entities that perform behavior such as business processes or functions.

A business role is assigned to each actor. (1) Client has the role of (3)Insurant and makes use of the Damage insurance product.

(2) ArchiSurance has the role as an (4) Insurer and is responsible for the Damage claiming business process, which is expressed by the assignment relation between the business process and the role.

(5) The Damage claiming process consists of four business functions.

In the example a distinction is made between “external” and “internal” behavior of (2) ArchiSurance.

The external visible behavior is modeled as business services: ( (6) Claims Registration Service, (7) Customer Information Service, and (8)Claims Payment Service) that are realized by the internal business functions: ( (A) Registration, (B) Acceptance, (C) Valuation, and (D) Payment) within the Damage claiming process.

These business services, together with a (9) contract, are grouped into a product.

The value of the product in this example is to be “insured” or “security”.

Other ArchiMate Resources:

  • The Open Group Certified ArchiMate 3 Tool
  • What is ArchiMate? How to Draw ArchiMate Diagram?
  • How to Draw ArchiMate 3.0.1 Diagram?
  • Learning ArchiMate Tutorials
  • Physical Viewpoint Guide

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Architecture

What is business layer in 3 tier architecture?

What is business layer in 3 tier architecture?

The business layer is the third tier in the three-tier architecture. It is the layer where the business logic is implemented. The business logic is the set of rules that govern the business activities.

The business layer is the layer in a three-tier architecture that contains the business logic. This logic is responsible for performing the business operations, such as retrieving data from the database and performing calculations.

What is business layer in layered architecture?

The business layer is where the application’s business logic operates. Business logic is a collection of rules that tell the system how to run an application, based on the organization’s guidelines. The business layer is responsible for ensuring that the data in the application is valid and that the application is running according to the organization’s rules.

The Business-Logic Layer (BLL) is a component of a software architecture that is responsible for implementing the business logic of an application. The BLL is typically used to abstract the business logic from the data access layer (DAL) or the presentation layer (PL). This separation of concerns allows for greater flexibility and maintainability of the software.

What is business layer in 3 tier architecture?

The BLL can be used to validate user input, calculate derived data, and enforce business rules. It can also be used to perform tasks such as logging and auditing. The BLL is typically not responsible for directly accessing or manipulating the data in the database. Instead, it relies on the DAL to provide it with the data it needs.

One advantage of using a BLL is that it can help to improve the performance of an application by caching data that is frequently used. Another advantage is that it can make the code more maintainable by encapsulating the business logic in a separate layer.

There are some disadvantages to using a BLL as well. One is that it can introduce a significant amount of complexity into an application. Another is that it can make it more difficult to unit test the code.

What goes in the business layer

The business layer is responsible for implementing the business logic of an application. This logic is specific to the problem that the application is designed to solve and might include tasks such as data analysis, salary calculations, or workflow management.

What is business layer in 3 tier architecture?

The Business Layer is used to model the operational organization of an enterprise, whereas the Strategy Layer is used to model the strategic direction and choices of the enterprise.

What is business layer vs service layer?

The service layer is usually constructed in terms of discrete operations that have to be supported for a client. For example, a service layer may expose creating an account, whereas the business layer may consist of validating the parameters needed in creating an account, constructing data objects to be persisted, etc.

The Application layer should only contain minimal logic. Business logic should only work and validate on the data itself. This is why it frustrates me to see embedded SQL in the Application layer, where no-one in the Business logic can re-use it!

What is business logic layer with example?

Data validation is a process of ensuring that data is clean, consistent, and accurate. It typically describes a series of protocols that occur after employees create or change lines of data. For example, business logic for a retail store might contain inventory information and can help track how many products you sell in a specific timeframe. Data validation can help improve the quality of your data and make sure that it meets the requirements of your business.

What is business layer in 3 tier architecture?

There are a few key parts to MVC that handle different aspects of an application. The Model is responsible for data and business logic, the View is responsible for presentation, and the Controller is responsible for receiving user input and deciding what to do.

A Business Rule is part of Business Logic. It is a statement or set of conditions that define how a business should operate. Business rules can be specific to a particular application or module, or they can be more general guidelines that are followed throughout an organization.

What are the 3 parts of a business plan

Financial planning, understanding the competitive landscape, and defining company values, vision, and mission are the three most important elements of a successful company. Without these key components, a company will likely fail.

What is the role of business service layer in SOA?

What is business layer in 3 tier architecture?

The services layer is the heart of a SOA and contains the service contract and descriptions for all business capabilities and services. At design time, this layer contains the service descriptions for business capabilities and services as well as their IT manifestation. At runtime, the services layer contains the service contract and descriptions for all business capabilities and services. This layer is critical for ensuring that the correct service is invoked for the correct business function.

The Business Layer in IDT consists of metadata objects like dimensions, measures, attributes, and filter conditions. Business layer can be designed on the top of Data Foundation layer or can be created directly on an Info cube or on a Modeling view in HANA.

What is domain vs business logic

Domain logic refers to the rules that govern the overall operation of a system. This includes the relationships between different objects and how they interact with each other. Business logic, on the other hand, describes how each object uses those relationships to achieve a specific goal.

Business logic is important because it ensures that a business is run in a consistent and effective manner. Application logic is important because it allows businesses to automate their business processes and make them more efficient.

What are the layers of application architecture?

What is business layer in 3 tier architecture?

Each layer in an application architecture plays a vital role in the overall success of the project. The design layer sets the look and feel of the project, the frontend layer handles the interactivity and visual elements, the backend or data layer manages the data and processes, the platform layer ensures compatibility with the targeted browsers/OS, and the business layer is the “brains” behind it all.

The data layer manages the physical storage and retrieval of data. This layer is responsible for storing data in a structured format in a database, and for retrieving data from the database as needed.

The business layer maintains business rules and logic. This layer is responsible for validating data, ensuring that data is accurate and consistent, and for performing any necessary calculations.

The presentation layer houses the user interface and related presentation code. This layer is responsible for generating the user interface, and for handling user input and output.

What is the business layer in MVC

The business Service layer is a great way to keep your Controller logic clean andseparate from your business logic. This also allows you to unit test your business logic separately from your request processing logic.

The controller’s job is to act as a go-between for the domain service and the view. The controller should take care of accepting requests and sending responses to the appropriate views. All of the business logic should be handled by the domain service. This will keep the controller slim and focused, and help to keep the domain service organized.

The business layer is the middle tier of a three-tier architecture. It is the layer where business logic is implemented. This logic encompasses all the rules and processes that govern the data in the application. In a three-tier architecture, the business layer is responsible for communicating with the other two layers (the presentation layer and the data layer) to process requests and return results.

The business layer is the heart of the 3 tier architecture. It is responsible for all the business logic and data manipulation. The business layer is typically divided into two parts: the presentation layer and the data access layer.

what is a business layer model

Jeffery Parker

Jeffery Parker is passionate about architecture and construction. He is a dedicated professional who believes that good design should be both functional and aesthetically pleasing. He has worked on a variety of projects, from residential homes to large commercial buildings. Jeffery has a deep understanding of the building process and the importance of using quality materials.

Leave a Comment Cancel reply

IMAGES

  1. Business layer example model

    what is a business layer model

  2. What is Business Layer in ArchiMate? Learn By Example

    what is a business layer model

  3. Business layer example model

    what is a business layer model

  4. Architecture of Business Layer working with Entity Framework

    what is a business layer model

  5. 8. Business Layer : ArchiMate® 3.1 Specification

    what is a business layer model

  6. Creating a Business Logic Layer (C#)

    what is a business layer model

VIDEO

  1. TYPES OF BUSINESS MODELS WITH EXPLANATION AND EXAMPLE

  2. Types Of Business Model Discussion in this Video // Business Model Discussion

  3. Types Of Business Model Discussion in this Video // Business Model Discussion

  4. # Business Environment Working Model 3D Model Commerce Exibition Business Studies Environment

  5. 48 Creating business layer to return elastic data in controller

  6. Business Layer part 1

COMMENTS

  1. Common web application architectures

    These layers are frequently abbreviated as UI, BLL (Business Logic Layer), and DAL (Data Access Layer). Using this architecture, users make requests through the UI layer, which interacts only with the BLL. The BLL, in turn, can call the DAL for data access requests. ... The Application Core holds the business model, which includes entities ...

  2. Creating a Business Logic Layer (C#)

    Creating a Business Logic Layer (C#) | Microsoft Learn Learn .NET ASP.NET 4.x Creating a Business Logic Layer (C#) Article 07/11/2022 9 contributors Feedback In this article Introduction Step 1: Creating the BLL Classes Adding the Other Classes Step 2: Accessing the Typed DataSets Through the BLL Classes Show 6 more by Scott Mitchell Download PDF

  3. Business-Logic Layer

    In summary, The Business-Logic Layer (BLL) is a component of a software architecture that is responsible for implementing the business logic of an application. It sits between the presentation layer and the data access layer, and is responsible for processing and manipulating data before it is presented to the user or stored in the database.

  4. Architecture of Business Layer working with Entity Framework

    The Business Layer is the place where all the business/domain logic, i.e. rules that are particular to the problem that the application has been built to handle, lives. This might be salary calculations, data analysis modelling, or workflow such as passing a order through different stages.

  5. What Are the 5 Primary Layers in Software Architecture?

    In software architecture, layers act as individual processes within the infrastructure of an application. These layers typically form a pattern, also called the n-tier architecture pattern. This is the industry standard for many applications and it's a widely known concept by many designers, engineers, architects and developers.

  6. What is business layer in software architecture?

    The Business Layer is used to model the operational organization of an enterprise in a technology-independent manner. The Business Layer contains elements that represent the various processes, roles, objects, activities, and services that make up the enterprise. The Business Layer is used to model the enterprise in a way that is independent of ...

  7. design patterns

    Business layer: Domain logic - Application logic. Data layer: Data repositories - Data access layer. The model that you see above means that you have an application that uses MVC, DDD and a database-independed data layer. This is a common approach to design a larger enterprise web application.

  8. The Business Model: Layer Player. What it is, How it Works, Examples

    A company employing the Layer Player business model typically concentrates on one or just a few activities within a value chain. It serves multiple market segments across various industries and its typical customer is an Orchestrator, who outsources the majority of value chain activities to specialized service providers.

  9. ArchiMate® 2.1 Specification

    3.2.1 Business Actor. A business actor is defined as an organizational entity that is capable of performing behavior. A business actor performs the behavior assigned to (one or more) business roles. A business actor is an organizational entity as opposed to a technical entity; i.e., it belongs to the business layer.

  10. Business logic

    Model real-life business objects (such as accounts, loans, itineraries, and inventories) Business logic comprises: [1] Workflows that are the ordered tasks of passing documents or data from one participant (a person or a software system) to another. Business logic should be distinguished from business rules. [2]

  11. Data Modeling Layer & Concepts

    For the sake of convenience, we will call them 'data modeling layer' tools. Conceptually, they present a 'data modeling layer' to the analytics department. A data modeling layer is a system that contains the mapping between business logic and underlying data storage rules of your business. It exists primarily in the ELT paradigm, where ...

  12. 8. Business Layer : ArchiMate® 3.1 Specification

    Business Layer elements are used to model the operational organization of an enterprise in a technology-independent manner, whereas strategy elements (Chapter 7) are used to model the strategic direction and choices of the enterprise. 8.1 Business Layer Metamodel Figure 52 gives an overview of the Business Layer elements and their relationships.

  13. Business Logic Layer And Why It Matters To Understand Blockchain

    Business logic layer (BLL) - as we have noted, the BLL deals with application processing and coordinates the flow of data between the UI and DAL. Data access layer (DAL) - or the layer where data management takes place. In most cases, this is via a web service or database.

  14. Business Logic Layer

    An enterprise-based WMS is made up of a three-layer structure which includes the interface layer, data access layer, and the business logic layer. The three-layer structure of the WMS is introduced below. •. Data access layer: This layer directly connects with the database and accesses the data.

  15. Business Layer

    Example In the model below, the business role Insurance Seller is fulfilled by the Insurance Department actor and has telephone as a provided interface. The business role Insurance Buyer is fulfilled by the Customer actor, and has telephone as a required interface. Image result for archiMate business role visual paradigm Business Collaboration

  16. What is Business Layer in ArchiMate? Learn By Example

    What is Business Layer in ArchiMate? Learn By Example On: February 20, 2018 In: CH 12 - ArchiMate: Learn by Examples With: 0 Comments ArchiSurance - Business Layer Example In this example, (1) Client and (2) ArchiSurance are business actors, the active entities that perform behavior such as business processes or functions.

  17. What is business layer in 3 tier architecture?

    The business layer is the middle tier of a three-tier architecture. It is the layer where business logic is implemented. This logic encompasses all the rules and processes that govern the data in the application. In a three-tier architecture, the business layer is responsible for communicating with the other two layers (the presentation layer ...

  18. Business logic layer in ASP.NET MVC

    The data model has all the data types to be used in the project and the business models do have additional logic related to the project. In addition to it there is going to be a data layer of the application which talks to the database. I am going to create a class library project for this data layer which will talk to database.

  19. Business Layer Elements

    Table of Business Layer Elements. Business Actor. A business actor represents a business entity that is capable of performing behavior. Business Role. A business role represents the responsibility for performing specific behavior, to which an actor can be assigned, or the part an actor plays in a particular action or event. Business Collaboration.

  20. Business Layer

    Business Layer. 1 min. Covering everything from Business Drivers, Goals, Business Principles and Business Capabilities to logical and physical Business Processes, organisation actors and sites. Key Classes and Relationships. We have broken out the business layer relations as they are quite broad, the other layers are within the diagrams

  21. MVVM: ViewModel and Business Logic Connection

    Moving all Logic into the Model Layer. Only keeping presentation Logic in the ViewModel. Con: Makes UI Notification realy painful If Data is Changed inside the Model Layer. ... (I call it Application Logic) + Model (Business Entities, or DTOs) = Business Logic Any code that does any calculation using available data is part of Business Logic.

  22. Creating a large language model from scratch: A beginner's guide

    d_model: The dimensionality of the input (and output) of the layer. num_heads: The number of heads in the multi-head attention mechanism. dff: The dimensionality of the inner layer in the feed-forward network.