Question

Supposing a classic 3 tier application. In DAL, you have a GenericRepository where T represent your POCO class and it include some method like Insert(T entity), Delete(T entity), Update(T entity) and so on. Then, your BLL (business logic class) contains something like CustomerRepositor.
Well, all rights.

Now, image your aspx page:

var customers = BLL.CustomerRepository.GetAll();
customers.First().Name = "some name"; 

Not good, you have to pass by CustomerRepository.Update, Insert or Delete methods in order to I can execute some validation for all CRUD operations. In this way all business logic will not works as I aspected.

I note that no-one has never thought about this, but I think is an important question. has not make sense to have business method for CRUD operation if yuo can bypass them.

Am I missing something?

Answer 1

Well, lets start.

var customers = BLL.CustomerRepository.GetAll();

This was a nice line of code in the last millenium. Before generics and LINQ came along. Seirously.

These days, I would expect it at least to be like this:

var customers = BLL.Repository<Customer>.ToList (); //IF you have to materialize

There is no need for an “All” method at all 😉

Am I missing something?

To a large degree an understanding that you are still within an application, so compromises are sort of acceptable. It is not like you run a trust boundary between applications here. Second, the fact that you should have programmed a better abstraction.

Repository repository = BLL.GetRepository ();
var customer s repository.Entity<Customer>.ToList ();
customer[0].Name = null;
repository.ValidateU ();
repository.Commit ();

would be a lot better abstraction. Creation is not done with “new” but with

var newCustomer = repository.Create<Customer> ();

which then commits.

All validation can be checked in the Validate method.

At the end, this is about HOW you design your interface for the repository – and if you insist on not keeping any state (which is a valid pattern for some operations) then this opens you to problems. And yes, you can have repositories that do not do full validation – totally valid. It really depends. You may be surprised, but I work on applications mostly where the repository is often not even updated in the same transaction as the object for performance reasons, and updates are queued and then batched, while the in memory version is the relevant one for all further operations.

It shows, at the end, that a little more thinking about how to design the DAL interface is in order, and please please please stop using an approach that is totally outdated and just leads to method creep (as you need tons of methods that otherwise just disappear in generics + linq expression trees.