Develop Reference

Design of Data Access Layer with multiple databases

I have read many posts concerning the issue of having several databases and how to design a DAL efficiently in this case. In many cases, the forum suggests to apply the repository pattern, which works fine in most cases.
However, I find myself in a different situation. I have 3 different databases: Oracle, OLE DB and SQLServer. Currently, there exists a unique DAL with many different classes sending SQL queries down to a layer below to be executed in the corresponding database. They way the system works is that two of the databases are only used to read information from them, and the other one is used to either store this same information or read it later on. I have to propose a better design to the current implementation, but it seems as if a common interface for all three databases is not plausible from an architectural point of view.
Is there any design pattern that solves this situation? Should I have three different DALs? Or perhaps it is possible (and advisable) to apply the repository pattern to this problem?

Answers to your question will probably be very subjective. These are some thoughts.
You could apply command-query separation. The query side integrates directly with your data layer, bypassing any business or domain layer, and the returning entities are optimized for read and project from your databases. This layer could also be responsible to merge results from different database calls.
The command side consists of command handlers, using domain or business entities, which are mapped from your R/W database.
By doing this, the interface that you expose will be more clear and business oriented.
I'm not sure that completely abstracting out the data access layer with custom units of work and repositories is really needed: do the advantages outweigh the disadvantages? They rarely do, because you will you ever change a database technology? And if you do, this probably means a rewrite anyway. Also, if you use entity framework code first, you already have unit of work and an abstraction on top of your database; and the flexibility of using LINQ.
Bottom line - try not to over-engineer/over-abstract things; or make things super-generic.

Your core/business code should never be dependent on any contract/interface/class that is placed in the DAL layer of the application.
Accessing data is something the business/core layer of your application needs to be able to do, and this it should be able to do without any dependency of SQL statements and without having any knowledge of the underlying data access technology.
I think you need to remove any "sql" statements from the core part of the application. SQL is vendor dependent and any dependency to a specific database engine needs to be clean out of you core, and moved to the DAL where it belongs. Then you need to create interfaces that resides outside of the DAL(s) which you then create implementation classes for in one or many DAL modules/classes. Your DAL can be dependent of your core, but not the other way around.
I don't see why the repository layer can't be used in this case. When I have a database which I can only read from, I usually let the name of the repository interface indicate this, like ICompanyRepositoryRead.

Designing Data Access Layer using C#, SQL Server

OK, as the title suggests I am designing a data access layer for a survey framework I am currently working on.
We all are familiar with the layered architecture notion, we try to achieve separation between the layers in a way that presentation layer can be hooked to any business layer, in the same way business layer can be wired to any Data access layer regardless of its implementation as long as it maintains the same interface (Same methods).
Now, after building the database using SQL Server, I am building the DAL using a DataSet (*.xsd) file and in this file I create the methods for each table adapter and the corresponding stored procedures in the database.
After working for a little while with the data set visual designer in Visual Studio I have noticed that I am aiming at providing a very flexible API that provides all the possible queries for the user in the form of methods. For example, I want to provide the user with methods that performs retrieval operations on the tables using any possible filter or with not filter, I also want the user to be able to delete rows using any column she/he wants as filter, also updating all/individual fields using any column he wants as a filter.
The way I have accomplished this primarily is by creating a method for every possible query whether it is DDL or DML. Now, when I think that I might made a mistake in a certain method or that I want to check the methods to make sure I did not miss anything while fast typing it seems like a pain because I have ended up with a ton of methods.
So, my question is: Is there another way for designing the data access layer so that it can be easy to refactor the methods and create them?
I hope I did not elaborate too much but I wanted to put you in the picture so I can get the correct answer, thanks in advance

Well, you could use an ORM tool to provider a good data access layer. I mean it because with an ORM tool you will have support to most of populars databases as SQL Server, Oracle, MySQL, PostgreSql, etc.
Depending of wichi ORM tool you use, you do not have to write SQL statments, which means you will be less sensitive to error an query.
I recommend you to check a tool called NHibernate. With this ORM you can write queries using Linq and another one (more specific for NHibernate) called QueryOver. You will have a lot of flexibily to write dynamics queries.
With an ORM tool you could implement a Repository Pattern and create methods and queries to get working data access.
So, when you use something like this, you will have the benefits of the Visual Studio like Refecting, because Linq, and QueryOver is strongly typed. But you will have HQL too, it like Sql Statment.
Check this article: Why I don't use DataSets

.net, C# Interface between Business Logic and DAL

I'm working on a small application from scratch and using it to try to teach myself architecture and design concepts. It's a .NET 3.5, WPF application, and I'm using Sql Compact Edition as my data store.
I'm working on the business logic layer, and have just now begun to write the DAL. I'm just using SqlCeComamnds to send over simple queries and SqlCeResultSet to get at the results. I'm starting to design my Insert and Update methods, and here's the issue - I don't know the best way to get the necessary data from the BLL into the DAL. Do I pass in a generic collection? Do I have a massive parameter list with all the data for the database? Do I simply pass in the actual business object (thus tying my DAL to the conrete stuff in the BLL?).
I thought about using interfaces - simply passing IBusinessObjectA into the DAL, which provides the simplicity I'm looking for without tying me TOO tightly to current implementations. What do you guys think?

I don't think there is a simple answer to your questions because there are many options depending on the circumstances. I have found it helpful to read the two books below to help me understand the problems you describe better.
MS .NET: Architecting Applications for the Enterprise (Esposito, Saltarello)
MS Application Architecture Guide, 2nd edition.
The second book is available online. Look here.

I think it is OK to pass the Business object to the Data Access Layer. I think the BLL's job is just to work with its objects, to check if all rules are being followed, about what can be saved, by whom, on what fields, time, etc.
Once it has done that it should pass it to the DAL, and I think it is IT'S job to figure out how to convert what it got into something that can be persisted, but it wont check what is being persisted or read or by whom, it will just do it. This could be straight foward, a la linq, but if your logic mdoels do not match your data model 1:1, then the DAL should do all the conversion.
About tying your DAL to the stuff in the BLL, I think you should worry about the other way around, tying your BLL to your DAL. I would use an interface to represent your DAL (as in IRepository) that way you can make your BLL call any kind of persistance mechanism just by changing the type of IRepository it is using (extra points if you use IoC :P). The concrete classes that implement the IRepository would be tied to the business objects, but they have to know what is it that they are saving don't they? while the BLL does NOT have to know what is doing the saving.

To pass business object in the DAL is the simpler and fastest method. It works in small projects, but have same disadvantages:
1) Business Objects are part of BLL layer, and if you pass objects in BLL then DAL becomes dependent of BLL. low layer knows about upper one - this contradicts the idea of layers at all.
2) Business Object are usially very complex to save it directly in BD. In this case it is better to introduce new "Mappers" intermediate layer.
To overcome all these issues I usially make interface to DAL independent of Business Objects. I use "Row" classes instead - representation of one record in the database or XML. In .NET 3.5 linqtosql autogenerated classes can be used for this purpose.

If I was in your position, I'd probably use LINQ to SQL to define my data access layer - it'll save you lots of work maintaining all that SqlCeFooBar stuff and give you a designer (of sorts) for maintaining your database that you would otherwise lack, using SQL CE.
So in that case, I'd probably couple the business logic layer pretty tightly to the entities exposed by the L2S layer. The justification being that the entities are the business objects, albeit devoid of any services.
I probably wouldn't let the entities get as far up the hierarchy as the UI though. At that level, it makes much more sense to use a model specifically for the view - especially given that you're using WPF.
Of course, all of this depends upon the size and complexity of your application. I'm assuming it's a fairly small scale application (single user?) given that you're using SQL CE.

ASP.NET C#: Which Design Pattern should I use and why?

I am developing an app in ASP.NET C# and came across the following scenario:
I will have to create some maintenance screens for different entities (tables)
Those entities will basically have the same behaviour within the UI: Search, GetById, Save, Create and GetAll
The entities may have different structure i.e. different properties (fields)
As I am talking about 20 plus admin screens, which design pattern I could take advantage of in order to minimize the amount of code I will have to write?
I though of the bridge pattern but I am a little confused on how to implement it ...
A little bit of the technology background I am using:
ASP.NET classic (n-tier)
LINQ to SQL and DAO objects
SQL Server 2005

For a set of admin screens that are just doing CRUD (Create, Read, Update, Delete) operations and with little in the way of business logic, I'd be quite tempted to more or less eschew design patterns and take a look at asp.net dynamic data. This is especially true if you want to minimise the amount of code you want to write.

This is not a design pattern... but I would strongly suggest using Dynamic Data. Jonathan Carter has some great articles about it: http://lostintangent.com/index.php?s=dynamic+data

If you're really just doing some basic stuff like this: Search, GetById, Save, Create and GetAll, I would recommend you use repositories. If done wrong repositories can get really bad and nasty, but if you're really primarily limited to this set of operations you've basically described a repository with that set of operations.
You'll want to look at ways in which you can extract the extra logic for example of searching so that you're not creating duplicate logic.
Repositories are nice and testable as long as you make sure not to let them get out of control. I give you this warning only because I've seen far too many people create monster classes out of repositories.
The repositories work with your objects. They are basically the intermediary which handles the persistence of your data. This abstraction allows you to hide from the rest of your code how you're persisting your data. In this case the implementations of your repositories will be using LinqToSql as I believe that is what you said you were using.
There are plenty of resources explaining the repository pattern.

What you want is not a design pattern. You are looking for an ORM with scaffolding. I have used and highly recommend SubSonic - http://subsonicproject.com. You can read about its scaffolding features here: http://subsonicproject.com/web-forms-controls/the-scaffold/

What is the best approach to make DAL?

I want to make a perfect custom DAL (data abstraction layer) class to use with all my projects.
I've searched the internet and found some samples for this but I never know which is the best approach.
Is it to make [Attributes]? Or use <Generics> or something else?
So please just give me a head line and I'll go on from there.
Thanks again and forgive my language.

Just make sure you:
Always use stored procedures
Never use stored procedures
Sometimes use stored procedures
Use nHibernate
Use SubSonic
Use Entity Framework
Write your own
Never write you own
Use POCO
Use ActiveRecord
Use IRepository
Always do what Fowler says
Never do what Fowler says
Don't use Linq to SQL, it's dead
Use Linq to SQL, it's no longer dead
Do all that and you will be fine.

Best approach is:
Don't do it yourself unless its for an academic research project or you intend to build a business shipping ORMs.
Try out the dozens of existing ORM solutions first. (Entity framework, subsonic, nhibernate etc etc...). They all have their quirks and limitations mixed in with tons of awesomeness.
ORMs are incredibly hard to get right and a huge undertaking.
Slightly related and on the money: http://wekeroad.com/2009/06/11/youre-not-your-data-access/

I can recommend you to read this article first. And take a look at EnterPrise Library's Data Access Application Block.

If you are a starter I would recommend use of SubSonic (more so if you are on web development).

as also one mentioned, don't try to implement a ORM tool yourself, there are a lot of them freely available. But a DAL isn't a ORM tool, the ORM tool will be used within your DAL. The DAL is just for hiding the data access logic from the rest of your app in order to have a more maintainable solution. In the end you could also have normal SQL statements i. your DAO class. What you should pay attention at when creating your DAL is to decouple it as much as possible from the rest of the app/other layers. This can be achieved by coding against interfaces and by using dependency injection. Spring is a great help here (given you program in Java). Beside that, there is no big magic on building such a layer.

Trying to create the ulimate, best, perfect DAL seems a bit crazy - there are so many different application scenarios with different and competing requirements and needs that I don't believe anyone can come up with THE ONE ultimate DAL.
You need to check out some of the existing ORM tools, get to know one or two of them, know their strengths and possibly drawbacks, and then be able to pick the best one for every given situation. I doubt it'll always be the same.....
SubSonic is great for smaller, nimbler projects - as is Linq-to-SQL, as long as you use SQL Server as your backend. If you need more enterprise power, you should look at NHibernate, ADO.NET Entity Framework, or other bigger, more capable players (which are just too complex and ill suited for a small, simple scenario).
I don't think there's THE perfect way to create a DAL - learn what's available, learn how to choose the one best suited to your current need, and don't reinvent yourself - use what's available out there!
Marc

Please read Data Access Layer Design Considerations

Definitely don't write your own persistence manager. You should use an Object-Relational Mapper (ORM) if you want to start from a class structure and have the ORM generate the SQL table structures for you, or use an SQL Mapper if you want to start from SQL tables and want to have your classes represent table rows.
I've had great experience using the iBatis SQL Mapper, and a lot of people like Hibernate for an ORM (though there's a learning curve).
Martin Fowler describes several good approaches for writing data access layers in Patterns of Enterprise Application Architecture (here's a catalog).
For instance, iBatis for .NET uses Fowler's Table Data Gateway pattern. In iBatis you specify Table Data Gateway objects in XML. Each Gateway typically governs access to one SQL table, although you can do multi-table operations too. A Gateway is composed of SQL statements, each wrapped in a bit of XML. Each SELECT returns one or more row objects, which are just sets of attributes plus getter and setter methods (in .NET these are called POCOs or PONOs, Plain Old C# Objects or Plain Old .NET Objects.). Each INSERT or UPDATE takes a POCO as its input. This seemed pretty intuitive, and not too hard to learn.

Linq to SQL is the best solution or you can try da easiest solution http://fluentado.codeplex.com/