1

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?

Edit:

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/

jmrah
  • 5,715
  • 3
  • 30
  • 37

2 Answers2

1

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

piotrek
  • 13,982
  • 13
  • 79
  • 165
  • I don't see a problem if I need to refactor when the time comes, however, you've provided insight that never occurred to me before. I particularly like the point about business requirements trickling in, and being able to convince the business for more time and money to refactor. Thanks for your comment. – jmrah Mar 14 '14 at 11:02
0

Ideally you should use the business layer, especially when you are using ORM. When you use ORMs the entities are referencing to each other.

You never know when incoming Business Object needed to be split, merged to adapt to data layer.

You never know if you want to add some business logic later on. So it's better to have a separate layer even if you do no transformations at the moment.

Ameer Tamboli
  • 1,218
  • 12
  • 20