Uniface Entity Services: Your Database Bodyguard 🛡️

Hey fellow developers! 👋

If you’ve been working with Uniface for a while, you’ve probably heard about Entity Services (ESV). Maybe you use them daily, or maybe you're still wondering, "Why do I need this when I can just put code in my form?" 🤔

Today, let's clear up the confusion! We’re going to look at what an Entity Service actually is, why it’s your database's best friend, and how it saves you from spaghetti code. 🍝❌

---

What is an Entity Service? 🛡️

Think of an Entity Service as a dedicated bodyguard for a specific database table.

In a 3-tier architecture, it sits right between your business logic (like a Session Service) and the physical database. Its sole job is to handle the Data Access Logic for one single entity (table).

It doesn't care about the user interface. It doesn't care about the big picture workflow. It only cares about one thing: ensuring that every record created, updated, or deleted for its specific table follows the rules.

The "Why" - A Simple Scenario 🏪

Imagine you have a CUSTOMER table.

Scenario A: The "Old School" Way (No ESV) 😱

You have 3 different places in your app where you create a customer:

1. The CRM Desktop Form 🖥️
2. The Web Registration Page 🌐
3. A nightly Batch Import job 🌙

If you want to ensure that every customer has a valid email address, you have to copy-paste that validation code into the write trigger of all three components. If the rule changes? You have to find and update all of them. Good luck! 😅

Scenario B: The "Clean" Way (With ESV) ✨

You create one Entity Service: ESV_CUSTOMER.

You put the email validation logic inside the write or validate trigger of this service.

Now:

• The CRM Form asks ESV_CUSTOMER to save the data.
• The Web Page asks ESV_CUSTOMER to save the data.
• The Batch Job asks ESV_CUSTOMER to save the data.

If the rule changes, you update one file. Boom! Done. 💥

How it fits into the Architecture 🏗️

Here is the flow of a typical Uniface application:

1. Presentation Tier (Form/DSP) 🖥️ User clicks "Save". The form calls a Session Service.
2. Business Tier (Session Service) 👔 Decides WHAT to do. (e.g., "Process this new Order"). It calls the Entity Service to handle the details.
3. Data Access Tier (Entity Service) 🛡️ Decides HOW to save it. Checks validity (Is the email valid? Is the ID unique?). Performs the actual I/O.
4. Database 💾 Stores the data.

When should you use them? 💡

Use an Entity Service when:

• ✅ You have validation rules that must always apply, no matter where the data comes from.
• ✅ You want to centralize your CRUD (Create, Read, Update, Delete) logic.
• ✅ You want to keep your forms lightweight and stupid (UI should handle UI, not data rules!).

A Common Pitfall: "Chattiness" 🗣️

One thing to watch out for! ⚠️

If you need to process 10,000 records in a loop, calling an Entity Service 10,000 times might be slow because of the overhead (instantiating the service, communicating, etc.).

Pro Tip: For bulk operations, consider passing a collection or list to the service, or keep the service instance alive (stateful) during the loop instead of creating/destroying it every time. 🚀

Summary

An Entity Service in Uniface is your key to:

• Consistency: Rules are defined once, applied everywhere.
• Maintainability: Change logic in one place.
• Security: The database is protected from "bad" data coming from anywhere.

So next time you reach for the write trigger in a Form... stop and ask yourself: "Shouldn't an Entity Service be doing this?" 😉

Happy Coding! 💻✨

Does this explanation click for you? Let me know in the comments below! 👇