System functions Vs Entity classes

[Khp Virajith]

hello,

I have a confusion with entity classes. as far as I know entity classes are directly mapped to database entities (tables). I want to know in which classes business functions(eg. in a Library System, reserveBook(),checkoutBook() so on...) should be implemented. Do I need to put business functions to a set of separate classes or can I keep them in relevant entity classes? Actually I want to know what the best & accepted (If any standard exists) way of doing it. I hope it'll be really helpful if I give you an example.

For the simplicity, let's say that we're designing a library system. I want to know in which class reserveBook() method should be implemented. In Book entity class or In Member(entity) class or In a separate class reserved for business functionalities such as Services.

Some people say that reserveBook() should be implemented in Book(entity) class because it's a function relevant to book entity. Some guys say that it should be implemented in Member(entity) class since it's a function of a library member. Others believe that method should be implemented in a separate class likes a Service in order to keep Book(entity) class as a pure entity class that is directly mapped to a database table.

I would be grateful If you can help me to solve my problem using this little example since it seems to be more effective.

At a first glance, Somebody may think that no point of asking such a question because, the system can be developed somehow without considering in which class these functions should be implemented. But the problem is I'm doing my final year project and they'll evaluate both design & implementation and also check the consistency between design & implemetation. Therefore I have to clearly figure out where business functionalities should be implemented.

Best Regards,
VIRAJ

[Frank Carver]

I develop my code in a Test-Driven way. Typically this drives each major design decision into its own class. So, the decision how and where to store an entity goes into one class - say DatabaseBookStore - which implements an interface common to all types of BookStore. Other implementations might be an InMemoryBookStore or a MockBookStore used for testing other parts of the system.

One advantage of this approach is that if (for example) you decide to switch from storing your data in a MySQL server on localhost, to using an Oracle or MSSQL server on a remote machine, all that is needed is to write and test a new BookStore implementation, then "plug it in" to your system in place of the old one.

In this style of design, business-level operations such as reserveBook() usually belong to one or more other classes given a BookStore as a parameter (either a constructor parameter or a setter) and which will therefore work with any kind of BookStore.

Has that helped?

[Ilja Preuss]

There is not *one* standard way of doing this, but there is a set of patterns (a pattern language) that deal with this kind of thing. Depending on the forces on your design, you would choose a different pattern. I highly recommend the book "Patterns of Enterprise Application Architecture" by Martin Fowler. http://www.martinfowler.com/eaaCatalog/

The pattern I find myself using most often is that of a Data Access Object (DAO) aka Table Data Gateway. With that pattern, your domain object wouldn't need to be changed for different persistence mechanisms. But notice that Active Record is a valid alternative. You really need to carefully look at each pattern, study which forces they resolve and which consequences they have, and then decide what's the right way for your current situation.