0
Currently my Solution is organized more or less like this:
- View (Windows Forms)
- DAL (Data access, return business entities)
- BLL (business rules in general)
- Model (POCO’s representing any business entity)
Here’s an example of what a DAL layer class would look like
public ClienteModel ObterPorId(int id)
{
// Código que consulta o banco e retorna um ClienteModel
}
public List<ClienteModel> ObterTodos()
{
// Código que consulta o banco e retorna uma lista de ClienteModel
}
Note that I have separated the Models
in a specific DLL, however, when I need to obtain an entity from the database I need to do using DAL
and of Model
And that seems redundant to me.
I’ve seen projects where Models
were stored inside the dll itself DAL
.
This seems to me to make sense because all types (Dals, Models, etc) would be embedded in the same dll.
This is good practice/advisable or there is some good reason to separate Models into a specific DLL?
Separate the
Models
classDal
this is correct, imagine you create a list of Clients where each item represents a classDal
, Now that’s a problem ...– novic
@Virgilionovic In my case, I have a Client class that is in DLL Models and a Clienterepositorio class that is in DLL DAL, the repository class has a method with this signature. public List<Client> Get All(); so I understand that I wouldn’t have this problem that you described.
– Ewerton
Yes you have problems because all the items in the list would have this method in your old case not yet but, if to
List<DalCliente>
will have performance problems, but, you do what you think best I’m just indicating that it is not necessary and the way you are doing it is not redundant, redundant is what is done more than once (there is backup redundancy that is good, but code is not) and in case that doesn’t happen.– novic
I ask you why complicate what’s right? If you’ve seen someone doing it it might be that they’re doing it wrong and you don’t have to follow the same line.
– novic
No, no, I would never return a List<Dalclient> because in my case Dalclient is a class that has all methods of query to the bank, ie methods of type
public ClientePoco ObterPorId (id)
;public List<ClientePoco> ObterPorNome(nome)
;.– Ewerton
From the comments I realized that I had not expressed myself well the first time, so I made some edits providing code examples.
– Ewerton
What’s inside
ClienteModel
? I need this class to guide– novic