I'm working on an application where the vast majority of functionality is a one-to-one mapping between database tables and views. It's by far and away a pure CRUD application.
However, there are a FEW cases where there are some business rules involved. For example, if a user is creating a 'Restricted Test', entering the company information is required, but if it is not a 'Restricted Test', then company information is optional.
Is it OK in these scenarios to have the views directly consume the database objects without a middle business-object, and to only implement a business-objects for those cases where business rules are involved?
As a side question, I am using an ORM framework which does not allow me to implement getter/setter code on the entity fields. Therefore, all fields on these entity objects are essentially public and can be changed willy-nilly. Should this be reason enough to create a 'business-object' for each entity class just to protect invariants like PKs, etc?
I did find a very helpful post by Mark Seemann that seems to answer about half of my question quite well. http://blog.ploeh.dk/2012/02/09/IsLayeringWorththeMapping/
yes, it's ok to bypass services in crud. it's ok to generate a crud but... are you sure it will still be a crud in a 6 months? can you anticipate new business requirements. because if new logic comes, it will come slowly, one requirement after one. will you notice the moment when you have to rewrite the tiering? will you be able to convince the business that you need time and money to pay for that change? and other developers to spend their time on rewriting the code?
so from the design point of view: yes, it is perfectly ok. but in real life it can be dangerous