Hi All,
Originally our DataPortal_Fetch routine would query the DB and return multiple resultsets to generate our object model. We have moved our data access to a more abstract model where we have DA, DA.SQL, DA.EF, DA.DTO projects.
Where/how do we process the additional resultsets without creating a circular reference? For example, if our original DataPortal_Fetch called a stored procedure and then executed something like:
While (dr.Read())
{
… Populate first object
If (dr.NextResult())
{
FirstObject.Child = ChildObject.GetItems(dr);
}
}
A good example would be Users and Roles. If we retrieve both as two resultsets and populated the DTO.Users object in the DA.SQL and DA.EF where/how would we populate the DTO.Roles object?
I’m thinking we either do it within the DTO.Users Fetch routine which means we would have to instantiate the DTO.Roles object and then populate it. Or, we could return back to the DataPortal_Fetch and call the Roles.GetRoles() method.
The second option means we would ignore (or remove) the second resultset and query the DB again (a second round trip to the DB). The first option means we do not have encapsulation as the DTO.User’s object would have knowledge of the DTO.Roles object.
The circular reference happens since the User class/project references the DA project. In the DA project if we wanted to call the Roles.GetRoles() method we would have to create a reference to the project that contains the Users/Roles object.
Any suggestions or have I made this overly complex?
I am not sure if the solution we've implement is the most correct (in terms of encapsulation, functionality, etc...) but it works. In our DA.EF and DA.SQL we continue to retrieve our multiple result sets. Then we populate our Parent.DTO and Child.DTO objects and pass the DTO object graph back to the DataPortal_Fetch routines.
In the DataPortal_Fetch routine we populate the parent object and call the corresponding Child.GetChild() factory object passing the child DTO.
If there is a better way to do this, let me know.
That sounds correct. Everything references the DTO assembly, and it references nothing. And no other assemblies reference each other either - that's the normal way of approaching this scenario.
The only exception is that I usually also have a "DAL manager" assembly that is the gateway into the different DAL implementations. So the business library and DAL components all reference the DAL manager, and it references nothing (except maybe the DTO assembly).
This DAL manager can be implemented using a provider model, IoC/DI or any other indirection pattern of your choice.
That sounds correct. Everything references the DTO assembly, and it references nothing. And no other assemblies reference each other either - that's the normal way of approaching this scenario.
The only exception is that I usually also have a "DAL manager" assembly that is the gateway into the different DAL implementations. So the business library and DAL components all reference the DAL manager, and it references nothing (except maybe the DTO assembly).
This DAL manager can be implemented using a provider model, IoC/DI or any other indirection pattern of your choice.
Thanks for the confirmation as we could have chosen another way to solve this issue.
We are utilizing a DAL manager but I omitted those details as not to cloud the question with extra details that may not be relevant.
Hello,
I tried to solve this using code generation but it became a really tall order really fast. How many levels deep are you going?
Thanks
-Blake Niemyjski
Copyright (c) Marimer LLC