Pergunta

Roughly following some designs I've seen, I'm building an ASP.NET application where each of my business objects has an associated Repository and Service. The repositories use nHibernate's ISession to perform CRUD operations, and the corresponding service accesses the repository members.

When using an ObjectDataSource in ASP.NET, is it considered bad practice to bind it directly to a repository instead of to a service (thus entirely skipping the service layer)? Or is the service layer not really necessary when just performing simple CRUD operations?

// Repository interface
public partial interface IRepository<T>
{
    void Add(T entity);
    void Update(T entity);
    void Remove(T entity);
    ICollection<T> GetAll();
    T GetByKey(int _ID);
}

// Service example
public class TestService : IService<Test>
{
    private static TestRepository _repository;
    ...

    public virtual ICollection<Test> FindAll()
    {
        return (_repository.GetAll());
    }

    public virtual Test FindBy(int Id)
    {
        return (_repository.GetByKey(Id));
    }

    public virtual void Save(Test entity)
    {
        _repository.Update(entity);
    }

    public virtual void Add(Test entity)
    {
        _repository.Add(entity);
    }

    public virtual void Remove(Test entity)
    {
        _repository.Remove(entity);
    }
}
Foi útil?

Solução

Definitely your UI shouldn't know about the data access. Even though you are not manipulating the data coming from the database, it is a good practice to have at least one more layer(Service, or Business Layer) and let your UI interact with the service. If I were you, I would do a poorman MVC for the Asp.net so that I can unit test

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top