Business Objects

Introduction

The BO project contains business objects — plain C# classes that act as data transfer objects (DTOs) between the UI, DAL, and stored procedures. They carry form input, session-derived context, validation attributes, and query results without embedding database or HTTP logic.

Organizing BOs by module namespace keeps Payroll, Bills, Stock, and other domains separated while sharing root types like User and Login_BO.

Purpose

This page documents how BO classes are structured, named, and used so you can add new models that align with existing conventions and validation patterns.

When to Use

Consult this page when you:

• Create a new form or API payload model
• Map DataTable rows from DAL to typed objects
• Share a model between controller and DAL method signatures
• Locate the correct BO for a module feature

How It Works

Project role in the stack

BO has no dependency on DAL or UI. DAL and UI both reference BO.

Root-level types

Class	Purpose
User	Authenticated user profile, module flags, e-invoice fields
Login_BO	Login form wrapper with nested User and company list
CompanyMaster_BO	Company dropdown and master reference
StateMaster_BO	Shared state lookup

User includes data annotations for login validation:

[Required(ErrorMessage = "Login ID is required.")]
public string LoginID { get; set; }

[Range(1, Int32.MaxValue, ErrorMessage = "Company is required.")]
public int Compid { get; set; }

public bool Payroll { get; set; }
public bool Billing { get; set; }
public bool ZSTOCK { get; set; }
// ... module flags

Namespace organization

BO files are grouped by business domain under BO/:

Namespace	Examples
BO.Payroll	SalaryProcess_BO, EmployeeAttendance_BO, PayRollDashBoard_BO, BranchMaster_BO
BO.Bills	CreateBill_BO, PaymentReceiving_BO, CreditNote_BO, GetGenerateIRN_BO
BO.Stock	ItemMaster_BO, VendorMaster_BO, GeneratePurchaseOrder_DAL counterparts
BO.Registration	Reg_Dashboard_BO, EntryPermission_BO, CandidateApplicationList_BO
BO.Employee	Employee_BO, EmployeeFamilyDetails_BO, EmployeeBankIDProof_BO
BO.Administrator	UserAccount_BO, UserRole_BO, EMailConfiguration_BO, LoginUser_BO
BO. ESS	LeaveRequestApp_BO, LoanAndAdvance_BO, Reimbursement_BO
BO.Sales	SalesFollowUp, LeadAllowance_BO, SalesRegMasters
BO.Operation	GrievanceMaster_BO, IncidentMasterOperation_BO, ClientMasterOperation_BO
BO.AttendancePunching	AttendanceDash_BO, ShiftMaster_BO
BO.VerificationAndApproval	BonuVerification_BO
BO.Master	Shared masters like DesignationMaster_BO

Naming suffix

Most types end with _BO. Some legacy Sales types omit the suffix (e.g. SalesFollowUp).

Typical BO anatomy

namespace BO.Payroll
{
    public class PayRollDashBoard_BO
    {
        public int CompID { get; set; }
        public int BranchCode { get; set; }
        public int UnitCode { get; set; }
        public int DedMonth { get; set; }
        public int DedYear { get; set; }
        // Filter fields matching SP parameters
    }
}

Common property sources:

Source	Properties
Session	CompID, UserID, BranchCode
Form POST	User-entered fields, dates, amounts
Query string	Report filters, IDs
SP output	IDs after insert, status flags

Controller model binding

Login POST binds to Login_BO:

public async Task<ActionResult> Index(Login_BO Login_BO)
{
    Login_DAL objlogin = new Login_DAL();
    objuser = objlogin.GetLoginUser(Login_BO.User);
}

AJAX POSTs often bind directly to specific *_BO types or accept primitive parameters and construct BO manually.

DAL mapping

DAL methods accept BO instances, read properties into SqlParameter[], and map SqlDataReader or DataTable rows back to BO properties using DatabaseHelper null-safe converters.

Developer Notes

• Validation: Use [Required], [Range], [DataType] on BO properties for MVC model validation where applicable.
• No behavior: BO classes should not contain SQL, HTTP, or session access — keep them serializable DTOs.
• Cross-module employee data: BO.Employee types are shared across Payroll, Registration, and root EmployeeM screens.
• Administrator BOs: User and permission models live under BO.Administrator even though the UI Area is named Adminisration.

Match SP parameters

When adding properties to a BO, align names and types with the stored procedure contract documented in SQL Server — Git does not contain the full schema.

Examples

Fill BO from session before DAL call

var filters = new SalaryProcess_BO
{
    CompID = Convert.ToInt32(Session["CompID"]),
    BranchCode = Convert.ToInt32(Session["BranchCode"]),
    DedMonth = Convert.ToInt32(Session["StartMonth"]),
    DedYear = Convert.ToInt32(Session["StartYear"])
};
var result = new SalaryProcess_DAL().GetEmployeeList(filters);

Module flag source (not a separate BO)

Module access booleans live on User, stored in session as dtVerifyUser — not on a separate ModuleAccess_BO.

Bills e-invoice BO

BO.Bills.GetGenerateIRN_BO carries IRN request payloads; session supplies URLs and credentials (GenerateIRNUri, CDKEY, etc.).

Related Pages

• Data Access Layer
• Stored Procedures
• Session Management
• System Overview

Important Notes

Do not reference DAL from BO

Keep dependency direction clean: BO ← DAL ← UI. Circular references break the build.

Shared User type

BO.User serves both login binding and session storage. Extending it affects login mapping in Login_DAL and dashboard tiles.

Common Mistakes

Mistake	Consequence
Putting business logic in BO	Hard to test; violates layering
Mismatch between BO property and SP param	Runtime SQL errors
Creating duplicate BO for same SP	Maintenance drift
Wrong namespace import in controller	Resolves wrong type with same class name
Omitting _BO suffix on new types	Inconsistent with 95% of codebase

Next Steps

1. Read Data Access Layer to wire your BO into a DAL method.
2. Browse BO/<Module>/ in the solution for examples closest to your feature.