问题
I am creating my assignment project from scratch, I started off by creating a DAL that handles connection to SQL and can execute stored procedure.
The project later will be a CMS or Blog
My DAC or DAL is reading connection string from web.config and accepting arrays of SQL Parameters along with Stored Procedure Name and is returning output of the executed stored procedure in DataTable.
I am calling my DAC as follows(using class functions and sometimes using code behind)
Dim dt As DataTable = Dac.ReturnDataTable("category_select_bypage", New SqlParameter("@pageid", pageid), New SqlParameter("@id", id))
Which is working fine and i am assuming to complete my whole application by calling this DAC and insert and retrieve data using stored procedures or may be simple queries later.
But, i have showed this work to my teacher and he told's me that you are using a wrong approach and your code is not fulfilling the correct DAL approach.
So, i am now too much confused with DAL and DAC. Any How here are main questions.
1. What really is the difference between DAL and DAC
2. By using my approach, what kind of application is good to make with it ? Can i make shopping carts using this approach?
3. What is wrong with my approach ?
回答1:
I think you can start with these links:
- http://msdn.microsoft.com/en-us/library/aa581778.aspx
- http://martinfowler.com/eaaCatalog/ (Data Source Architectural Patterns)
- http://www.simple-talk.com/dotnet/.net-framework/.net-application-architecture-the-data-access-layer/ (it talks about DataSets, I guess you can use them until application is small or pretty simple: they're well known and deep integrated in many VS tools).
Take a look at the SO question too: How to organize Data Access Layer (DAL) in ASP.NET
回答2:
Adriano provided a very good link. Certainly a must read. But I do see one thing. When creating logical layers in an application, each layer is not aware of the inner workings of those beneath it. For example the presentation layer has no idea how the data layer gets data, it just magic. The reason for this is what if you decide to not use the SqlClient and chose a different technology. Now by using "Technology Hiding" with layers you can make that change quite easily.
So given what you have I'm assuming the DataTable is in the presentation (or application) layer. And, if this is true your DAC method call should not expose anything related to what or how it is retrieving data. In your case this rule is violated by the SqlParameter parameter. Perhaps you could pass string's or int's. For example:
public DataTable Dac.GetPage(int pageId, int id)
Never the less, best of luck. I'm glad to see those willing to learn and those willing to teach.
回答3:
I don't think returning DataSets could readily be described as 'wrong'.
Your DAL serves purely as an abstraction so (hypothetically) we can swap databases, or change from a database to an XML file or whatever. The rest of the application is unchanged.
As long as your business logic is happy with a contract that passes DataSets up from the DAL I don't think it's an architectural problem. It might be suboptimal, since DataSets can be quite expensive in terms of resources, but they are very well supported in .Net (they are the foundation of more simple architectures like the Transaction Script or Table patterns).
What you might have instead are some custom objects and have the DAL transform its SQL query results into those objects, so they can then be processed by the business logic layer.
But then I can think of situations where you just might want DataSets…
All subjective, of course ;)
回答4:
Function in Data Access SQLServer Layer:
public override DataTable abc()
{
//Connection with database
}
Function in Data Access Layer:
public abstract DataTable abc();
Function in Business Logic Layer:
public DataTable abc()
{
//Preparing the list
}
Function in Presentation Layer:
using (DataTable DT = (new BusinessLogicLayerClass()).abc())
{
}
The above approach is according to the DataTable. But it should insteadd return list of class to the presentation. The List preparation job should be done in Business Logic Layer.
回答5:
The problem with DataSet/DataTable is that it's a representation of your database. Using it everywhere would create high coupling to your database.
That means that you have to update all depending code every time you do a change in your db.
It's better to create simple classes which represent the database. by doing so you'll only have to change the internals of those objects (or the mapping layer) when the db is changed.
I recommend that you read about the Repository pattern. It's the most common way to abstract away the data source.
来源：https://stackoverflow.com/questions/9705794/is-returning-datatable-or-dataset-from-dal-is-wrong-approach