.NET Questions (CLOSED)

Questions and Answers on any aspect of .NET. Now closed.

This discussion group is now closed.

Have a question about .NET development? Try stackoverflow.com, a worldwide community of great developers asking and answering questions 24 hours a day.

The archives of .NET Questions contain years of Q&A. Even older .NET Questions are still online, too.

Entity/Domain Objects and DataAccess

2007 starts my year of opening up and ask some questions that are flaoting around in my head...

I strongly feel that objects should be ask simple as possible.  They should have one take or represent one "object" and that's it.

My question has to do with Entity/Domain Objects.  Say I have an employee class. The employee class has two properties, ID and Name (for simplicity sake).

1)  Where should the CRUD operations go?  Should that be handled in the Entity Object or in another class keeping with the idea that the Entity Object should only have one task.  In real-world terms I think of it this way, if I had a "cup" object, the operation Fill, would be a funtion of a "faucet" operation and not the "cup".  A "cup" is an an object that has no facilities to fill itself.

2)  If you've answered that the CRUD operations should be separate from the Entity Object, then typically how do you name this?  if I have a business class called Employee, what do I name the CRUD class?  how do I get around naming (namespace conflicts ect).


Fevir Send private email
Wednesday, January 10, 2007
I have a data access layer (DAL) which includes a class for each domain type, for example ...

interface IDalHelper<T>
  public void save(T record);
  public T select(Guid id);
  ... etc ...

class DalEmployee : public IDalHelper<Employee>
  public void save(Employee employee) { ... }
  public Employee select(Guid id) { ... }
  ... etc ...

... which help to implement a DAL which is a class like ...

class Dal
  //private DAL data includes SQL connection
  public void save<T>(IDalHelper<T> helperT, T record){ ... }
  public T select<T>(IDalHelper<T> helper, Guid id) { ... }

.. because layers which use Employee don't necessarily want SQL stuff in the implementation of the Employee class itself: Employee is a light-weight object (which can be remoted, for example).

My Dal class is hand-coded. The classes which implement the IDalHelper interface for each entity type are auto-generated (using a reflection framework that I hand-coded) from a definition file which defines the properties of the entity (e.g. Employee) and the entity's (foreign-key-like) relations to other types.

If I weren't using using templates as above, then in addition to the entity types there would be just a single Dal class which defines methods for each type, e.g. ...

class Dal
  //private DAL data includes SQL connection
  public void saveEmployee(Employee employee){ ... }
  public Employee selectEmployee(Guid id) { ... }
  ... etc ...
Christopher Wells Send private email
Wednesday, January 10, 2007
Yeah, I do persistence in a separate class - I call it EmployeeRepository. Read Domain Driven Design for some good ideas on organizing your classes.
Mike S Send private email
Wednesday, January 10, 2007
You can go either way and it will be fine. I actually go both ways. For standard CRUD, the CUD parts can be done simply by using metadata information. This allows you to centralize the code. For example, I have a base class that all domain objects inherit from that contains the insert, update, and delete statements. This means that there is only one update/insert/delete statement in my whole application. But since it is in the ancestor of the domain object you call a base "Process" function to trigger it.

But the R in CRUD is a different story. You will end up wanting to query/read by a variety of means. So I use a query object to hold all the possible sql for retrieving lists of the different types of domain objects.

So to give an example, if I want to update/insert an employee record I would use the following code.

Employee employee = new Employee();
// do something to the employee record

// Save the employee record. An update is performed
// if the record was retrieved from the database and
// an insert is performed if the record is new.

And if I want to read a list of employees by last name I would use a separate query object. Something like the following.

EmployeeQuery query = new EmployeeQuery();
List<Employee> list = query.ReadByLastName(lastName);
Turtle Rustler
Wednesday, January 10, 2007

I've been interested in this topic myself for a long time.  My "vision" of how I want this to work is that the developer they should be separate classes, but, importantly, most of the data access stuff should be automated by a library.  I'm currently implementing that "vision" here: http://www.activesharp.com/DetailedExample.aspx  (check out the bottom 3rd of the page).
John Rusk
Wednesday, January 10, 2007
>how I want this to work is that the developer they should be separate classes,

Opps should read: "how I want this to work is THAT THEY should be separate classes".
John Rusk
Wednesday, January 10, 2007
Check out the Microsoft Enterprise Library - Data Access Block. It does all the heavy lifting for data access, while providing a solid abstraction layer for talking to numerous data providers.

Then you can layer your entity objects on top however you want, it really doesn't make much difference which way you do it, in my experience - there are advantages and disadvantages to each approach that you need to be aware of and be able to relate to the needs of the application.

In the end, I favour the agile approach, which is to code the simplest possible solution that meets the known requirements of the application, and refactor constantly. I always start with simple Active Record objects because they are the easiest to program with as a consumer, and I only expand to a more complex architecture if the need arises.
Sam Piper Send private email
Thursday, January 11, 2007
It is a question without an only answer. I believe that thre will be a 'unique' way to do the CRUD operations at least in .NET Version 5 & JAVA Version 7. The only thing we can do is to be simple so 'we' can read and understand our own code after we released the application. I was experimenting and I found that the mos pure approach is to leave the object separate in a class (example Car_BEC.cs, BEC = Business Entity Component) and the CRUD operations in another class (example Car_BPC.cs, BPC = Business Process Component) and on top of these a Facade Class (example Car.cs) all of them belong to the BLL. Of course that these CRUD methods has to be provided by a DAL Class. After all there's no much on the web and once again we are alone also by the 'inventors' of the products we use to work.
Best regards to all of you Good Developers.
Frank Send private email
Tuesday, January 30, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz