I’m way tired of the architecture astronauts throwing around words, phrases, and jargon like application layer, application logic, domain, model, DDD( Domain Driven Design), thin, thick, services and on and on. Give me a break. They sound just as bad as the marketing guy who’s screaming about cloud services everytime he gets a chance. Clueless.
But, it’s not their faults. Microsoft has done a great job of building tools, frameworks, documentation, and guidance on everything but what will ultimately become the majority of any application, business logic. Thanks again Microsoft.
So I will try to clear the air. I hope I don’t sound like an architecture astronaut and actually say something. Business logic is verifying the email address field is formatted like an email address, its making sure that the Customer Name field is only 50 characters long, its making sure the start date is less than or equal to the end date, its making sure required fields are filled, its making sure that an invoice must have at least one invoice line, its making sure a user is not deleted from the system if he still has unfinished work, its all of the business rules. But wait, it doesn’t stop there. Business logic is also making sure the user can read a property, write to a property, execute a method, view this or that data, or even instantiate a type. Business logic is all the data validation, manipulation, processing, and authorization for the application.
Wow, now we know what we are talking about when we are using jargon like “fat model”. Its alot of code. Its all the code. It is the application. And as the most important piece it deserves architecture all of its own. Architecture on the order of writing a web development framework such as MVC. Architecture on the order of writing a data access framework like Entity Framework. But of course thats not what it gets. And by the way, Entity Framework is not suitable for business logic of any kind. And implementing the repository pattern does not constitute a business layer. Sorry, I don’t care what Microsoft or the architecture astronauts say.
However, there is hope. There is at least one brave soul who has recognized the importance of business logic and has addressed the issue with a full court press. Introducing Rockford Lohtka and CSLA. You remember that big yellow and black apress book you seen in Barnes and Noble, Expert C# Business Objects. The one you passed up for the latest do hicky book. Yeah, the only programming book that goes into drop dead from boredom details about business logic and how CSLA addresses the concerns. Yes, it was horribly boring, but now I understand precisely what business logic is, exactly where it should go, and what a business layer should provide to those that use it.
This isn’t a CSLA fanboy article. This is an article to harp on all the Microsoft sheep. Oops sorry thats not it either, well maybe a little, ok maybe a lot. But no really, understanding business logic has helped me out. If it wasn’t for digging deeper into the topic I would still be stuck trying to implement business rules in my EF entities using DataType attributes.
O and by the way, there are shorter more focused pdfs that cover the CSLA framework. If all you are interested in are Lhotka’s thoughts on business logic, very insightful, then you can get away with reading the CSLA.NET overview. You have to buy the whole set of pdfs though from the CSLA website, worth every penny even if only for one pdf.