Is it possible to use two different data sources with two different concrete DALs

Is it possible to use two different data sources with two different concrete DALs

Old forum URL: forums.lhotka.net/forums/t/12113.aspx


pecen posted on Wednesday, August 14, 2013

Hi,

What would be the proper way to code if you have two different data sources?

For instance, in my project I have a SQL2008R2 Data Source with the main data, and a XML file which defines the filter conditions of what to retrieve from the main database. I.e. the XML file have the criterias defined which I use when I want to select what to retrieve from the SQL database.

As it is now I have implemented both in my concrete Dal called DalSql, but I would rather have the XML implementation in its own concrete Dal.  

In my abstract Dal I have one interface called IOrtSettings, which defines methods for retrieving data from the SQL database, and one  interface called IOrtSettingsFilter which defines which OrtSettings to retrieve. These interfaces are then implemented in the concrete Dal, DalSql. 

Below is an example of the XML-file used with filter conditions. The CategoryId and VariableId fields are columns in a table in the SQL database, and the values are used to define what should be retrieved.

These filter options (MapDto's below) can also vary from client to client, so there is a scenario where you use an admin interface to set new filter options, which are then written to the XML-file, or delete existing filter options in the XML-file.

My problem is that since the XML-file have its own edit scenario, I'm not sure the way I've made my implementation is the best way to do it. It works, but shouldn't the XML-part have it's own area, like its own concrete Dal, for instance a DalXml?


<?xml version="1.0" encoding="UTF-8"?>
<OrtSettingsFilter xmlns="http://www.ortivus.com" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <MapDto>
     <CategoryId>Ortivus</CategoryId>
     <VariableId>SW-options</VariableId>
 </MapDto>
 <MapDto>
   <CategoryId>MMM</CategoryId>
   <VariableId>MMMLocation</VariableId>
 </MapDto>
 <MapDto>
   <CategoryId>MMM</CategoryId>
   <VariableId>MMMName</VariableId>
 </MapDto>
 <MapDto>
   <CategoryId>Hardware</CategoryId>
   <VariableId>MU1</VariableId>
 </MapDto>
 <MapDto>
   <CategoryId>InstalledMSI</CategoryId>
   <VariableId>Ortivus MMM</VariableId>
 </MapDto>
 </OrtSettingsFilter>

JonnyBee replied on Thursday, August 15, 2013

Hi,

So you are considering to create a separate assembly (and interfaces) for the Xml filter and configuration handling? 

Basically - it is a matter of how YOU want to structure your code.

How much work is involved to separate the DAL code and XML filer/configuration?

Do you plan on creating multiple implementations of the DAL to support a number of databases? 

If you are not going to create multiple implementations of the dal - you could just as well have one DAL assembly and still have the XML code isolated into it's own namespaces inside the DAL assembly. Again - it is how you structure the code - and I would create a separate assembly if I needed to use this code in several DAL assemblies.

pecen replied on Sunday, August 18, 2013

Hi, and thanks for your reply.

Yes, that's what I'm thinking as well, a matter of how one wants to structure the code. My thougt was to create a separate assembly for the Xml handling, so that not every concrete Dal have to also include code for handling the Xml config-file (although it is re-usable), and what if in the future it will be decided to use another format/db/source for the config part.

Today I have just one Dal assembly, and have the Xml-code isolated in its own namespace like you suggest. It just seems like I should take another approach with future possible maintenance issues in mind.

Again, the main question I haved is, if you have chosen the Encapsulated Invoke DTO approach, is it possible to have several Dal's, or is the proper way to take another approach?

/p

 

 

JonnyBee replied on Sunday, August 18, 2013

Hi,

In a repository pattern you would typically use interfaces and an IoC container so it is a question of configuring the IoC container to provide classes from the appropriate DAL assembly. Your DTO's should not change if you use another database but the IoC conainer will be configured to use a different set of classes.  

Copyright (c) Marimer LLC