I have a typical DAO to fetch SQL objects from a table, but now I need to be able to query for objects placed in another physical database using foreign keys. Due to restrictions in my ORM I cannot create a query that joins over the two databases and hence I need to do this reduction step myself. To not introduce dependencies between DAOs I thought to myself that I should increase the level of abstraction and introduce a service on top of this DAO that does this for me. Is this the way to go or am I more confused than I think I am?
Since your "increased level of abstraction service" will be still "DAO" (and nothing more) I would just call it DAO and inject your base DAO service.
Semantically it will be completely correct.
Related
I am new in the world of DAO Pattern, DAL and Domain Driven Design. I am trying to understand the DAO Pattern. Every example/tutorial says that DAO abstracts the way data is persisted for several datasources. But what is the result of using a DAO object?
Does DAO retrieve pur data (columns) from the database that always corresponds to exactly one table OR does DAO Pattern involve some kind of Object-Relational-Mapping that resolves and loads dependencies given by foreign keys in the database and providing a complete Business Object in the end?
I suggest you to take a look at the Session Façadepattern. It is useful to encapsulate business-tier components and expose a coarse-grained service to remote clients.
As described in this (old) reference:
I'm creating a framework MVC to build my applications. In my application I need to use several DBMS s and I need be prepared for that.
I'm thinking in to use Active Record pattern and it have the "connection" (abstract) associated. The Active Record don't know which DBMS to be used. So, I use Factory Method for have abstract which DBMS been used.
How will I build various queries (CRUD) ? Because each DBMS will need specific query.
I'm think that creating various classes "QueryBuilder" it will can to resolve (one class for each DBMS ).
What's think?
To resolve this issue, you can use DAO Layer Pattern. This pattern hides the database specific details from the client. You can define the interface for CRUD operation which your DAO will implement.
In this way, even your DB changes in future, client of DAO layer don't have to worry about the changes.
Refer below wiki page for more details about this pattern.
http://en.wikipedia.org/wiki/Data_access_object
I assume the intent is to insulate the various ActiveRecord objects from the SQL syntax variances between the DBs?
You didn't define what you exacty intended with a design for your query bulder, but I've done once with methods like AddSelection(colName), AddCriteria(colName, ComparisonEnum, value), etc. If that is your approach then if your queries are small/simple enough then a query builder would work. BUT as soon as you need the ability to build complex joins or inner subqueries then you may hit a wall with that approach.
If you need to handle arbitrarily difficult queries then another option is to create a converter or translator. If you were to define a canonical query format, then each DBMS-specific convert would know how to convert from that canonical format to the DB-specific syntax. You've really got to need this functionality to make it worth the effort though.
And finally, your other appraoch is to subclass the ActiveRecord for each DB. So if you have an EmployeeRecord class you can subclass it with OracleEmployeeRecord, MySqlEmployeeRecord, MsSqlServerEmployeeRecord, and the like. Then use an abstract factory to create the appropriate ActiveRecord objects.
I need to place some complex business logic into db for perfomance reasons and I'm using respository pattern. The question is - should I invoke this business logic from the repository? I know that the repository shouldn't be aware of BL because it's just a mediator between the BL and data storage (it should contain only CRUD and query methods).
What do you think?
The responsibility of a Repository is to provide a semblance of in-memory collection of entities to query from or add to. I don't know what kind of business logic you're talking about, but chances are it would break the single responsibility principle if you introduced it in a Repository. This would mean giving the Repository code many reasons to change, less cohesion and thus many reasons to break.
If you've got stored procedures with business logic in your database, I'd recommend you introduce some kind of interface between the calling code and the db to keep things decoupled. It wouldn't be a Repository since its purpose would be to trigger some business logic instead of persisting data, but the implementation could take the form of an Infrastructure Service for instance.
This will allow you to test your code in isolation using a mock db, and switch to another implementation of the db access interface to point to another DBMS, or even just to objects if you decide to give up on stored procedures at some point.
The application uses ADO.NET to invoke sprocs for nearly every database operation. Some of these sprocs also contain a fair amount of domain logic. The data access logic for each domain entity resides in the domain class itself. ie, there is no decoupling between domain logic and data access logic.
I'm looking to accomplish the following:
decouple the domain logic from the data access logic
make the domain model persistence ignorant
implement the transition to NHibernate gradually across releases, refactoring individual portions of the DAL (if you can call it that) at a time
Here's my approach for transitioning a single class to NHibernate persistence
create a mapping for the domain class
create a repository for the domain class (basic CRUD operations inherited from a generic base repository)
create a method in the repository for each sproc used by the old DAL (doing some refactoring along the way to pull out the domain logic)
modify consumers to use the repository rather than the data access logic in the class itself
remove the old data access logic and the sprocs
The issues I have are with #1 and #4.
(#1) How can I map properties of a type with no NHibernate mapping?
Consider a Person class with an Address property (Address being a domain object without an NH mapping and Person being the class I'm mapping). How can I include Address in the Person mapping without creating an entire mapping for Address?
(#4) How should I manage the dependencies on old data access logic during the transition?
Classes in the domain model utilize the old data access logic that I'm looking to remove. Consider an Order class with a CustomerId property. When the Order needs info on the Customer it invokes the ADO.NET data access logic that resides in the Customer class. What options are there other than maintaining the old data access logic until the dependent classes are mapped themselves?
I would approach it like this:
Refactor and move the data access logic out of the domain classes into a data layer.
Refactor and move the domain logic out of the sprocs into a data layer. (This step is optional, but doing it will definitely make the transition smoother and easier.)
You don't need a repository, but you can certainly create one if you want.
Create a NHibernate mapping for every domain class (there are tools that do this).
Create a NHibernate oriented data access API that slowly replaces the sproc data layer.
Steps 1 & 2 are the hardest part as it sounds like you have tight coupling that ideally never would have happened. Neither of these first two steps involve NHibernate at all. You are strictly moving to a more maintainable architecture before trying to swap out your data layer.
While it may be possible to create NHibernate mappings one by one and utilize them without the full object graph being available, that seems like asking for unnecessary pain. You need to proceed very cautiously if you choose that path and I just wouldn't recommend it. To do so, you may leave a foreign key mapped as a plain int/guid instead of as a relation to another domain class, but you have to be very careful you don't corrupt your data by half committing to NHibernate in that way. Automated unit/integration tests are your friend.
Swapping out a data layer is hard. It is easier if you have a solid lowest common denominator data layer architecture, but I wouldn't actually recommend creating an architecture using a lowest common denominator approach. Loose coupling is good, but you can go too far.
search more on the internet for nhibernate e-books
Refactor and move the data access logic out of the domain classes into a data layer.
Refactor and move the domain logic out of the sprocs into a data layer. (This step is optional, but doing it will definitely make the transition smoother and easier.)
You don't need a repository, but you can certainly create one if you want.
Create a NHibernate mapping for every domain class (there are tools that do this).
Create a NHibernate oriented data access API that slowly replaces the sproc data layer
The terms are often thrown around interchangeably, and there's clearly considerable overlap, but just as often it seems implied that people see something strongly implied by saying that a system is an ORM that isn't implied by it being a DAL. What is that? What, if any, are the key points that differentiate these types of system?
For example, let's say I have some code that implements Database, Table, Column and Row classes, populating them by automatic analysis of an existing database, allowing simplified interaction and so on. It understands, enforces, and takes advantage of structural relationships between database entities, such as foreign keys. All the entity models can be subclassed to load table-specific functionality onto them.
To what extent is this a DAL? To what extent is it an ORM? Why?
ORM = Object-Relational Mapping
In an ORM, classes/objects in the application are mapped to database tables and operations for persistence, sometimes automagically.
DAL = Data-Access Layer
In a DAL, database operations are hidden behind a code facade.
An ORM is a kind of DAL, but not all DALs are ORMs.
I think an ORM is capable of mapping any set of objects to a relational database; whereas a DAL is specific to your application, and probably couldn't naturally be extended to support other objects.
Not only that, but a ORM specifically is concerned with mapping classes to/from the database entities, while a DAL may simply be a way for you to access the data in a database, without any mapping.
Any object orientated DAL connecting to any storage system that is not saving objects implements an ORM. ORM is generally understood to mean something like Hibernate, but the important thing is the handling of impedance mismatches.
[Expanded]
At a data level, an impedance mismatches occur when you are mapping data of one type (relational) into data of another (OO).
For instance, how many times have you seen a line like below in your DAL?
db.AddInParameter(dbCommand, "Name", DbType.String, name);
Or the other side
customerId = Convert.ToInt64(dr["CustomerID"].ToString());
Many issues come up when mapping your primitive data types.
At a object level, your DAL should be returning the structures you intend to use. Be it some sort of business object or just a bunch of raw data. Both your own DAL and the ORM need to handle this.
At a design level, the objects you construct are reflective of your stored data. So a structural difference can occur. These are also handled for you within ORM solutions, but you would be forced to do the same within a DAL. For example, within your OO code it would be nice to implement proper inheritance, but that does not covert easily into something relational.
I just wanted to point out that ORM is a term coined to push products that automate a lot of what you would already have to do within your DAL. The ORM solutions will make life easier and provide a large number of quality/performance benefits. But that doesn't change the fact that one of the major components of your DAL is creating your own ORM.
ORM didn't exist when I started programming. When the first ORMs came out, they were external tools used to create the DAL. Now days, DAL and ORM have intermingled. That's why a lot of developers use the terms interchangeably.
The most well known example of an ORM that functions as a DAL is NHibernate. Other examples are Subsonic and CSLA.NET. These are all .NET tools. IIRC, ORM tools started in the Java world. Other technologies stacks then copied what Java has done.