ASP.NET Provider and DAL
-
Good Afternoon, I am new to ASP.NET. I am used to C# windows delveloper. In all my previous projects we had a seperate solution to handle the Data Access Layer. This layer had all the logic for logging in and communicating with the database. How do I move the Login (currently I am using Memberships that is setup in my config file) to the DAL layer? Should it be in the DAL layer? Thanks for all your help. Chris
-
Good Afternoon, I am new to ASP.NET. I am used to C# windows delveloper. In all my previous projects we had a seperate solution to handle the Data Access Layer. This layer had all the logic for logging in and communicating with the database. How do I move the Login (currently I am using Memberships that is setup in my config file) to the DAL layer? Should it be in the DAL layer? Thanks for all your help. Chris
Membership having it own internal implementation. If you want to move membership, you can use DAL for all database related code. Even inbetween DAL and UI, you can put the Business Layer also (BLL).
Abhijit Jana | Codeproject MVP Web Site : abhijitjana.net Don't forget to click "Good Answer" on the post(s) that helped you.
-
Good Afternoon, I am new to ASP.NET. I am used to C# windows delveloper. In all my previous projects we had a seperate solution to handle the Data Access Layer. This layer had all the logic for logging in and communicating with the database. How do I move the Login (currently I am using Memberships that is setup in my config file) to the DAL layer? Should it be in the DAL layer? Thanks for all your help. Chris
You're trying to keep seperation of concerns, as you should. The problem is, Asp.Net web applications are very much dependant on app and web.configs, which don't run in class libraries. I don't use .Net Memberships. I created my own role-based security model (did this before I started using .Net) and created data providers to go with it. Also, I use a ConnectionProviderFactory (returns an IDbConnection) class to maintain connection strings so my Dals can be completely independant from the applications using them. There are some useful features provided in .Net but if you require more abstraction and extensibility you sometimes need to break-out a little.
Mark Graham (MCP) blogging about Design Patterns, C#, Asp.Net, CSS, Javascript and Ajax at: DESIGN CODE TEST[^]
-
You're trying to keep seperation of concerns, as you should. The problem is, Asp.Net web applications are very much dependant on app and web.configs, which don't run in class libraries. I don't use .Net Memberships. I created my own role-based security model (did this before I started using .Net) and created data providers to go with it. Also, I use a ConnectionProviderFactory (returns an IDbConnection) class to maintain connection strings so my Dals can be completely independant from the applications using them. There are some useful features provided in .Net but if you require more abstraction and extensibility you sometimes need to break-out a little.
Mark Graham (MCP) blogging about Design Patterns, C#, Asp.Net, CSS, Javascript and Ajax at: DESIGN CODE TEST[^]
Hi Thanks for your input. :) Is it really worth going through all the trouble to implement a DAL layer? What is the cons of creating your own role-based security model? And how much work are we talking about. I am fairly new to ASP.NET. Coded alot in VB.NET and C#. When you did this how many stops did you find along the way? Thanks Christiaan
-
Hi Thanks for your input. :) Is it really worth going through all the trouble to implement a DAL layer? What is the cons of creating your own role-based security model? And how much work are we talking about. I am fairly new to ASP.NET. Coded alot in VB.NET and C#. When you did this how many stops did you find along the way? Thanks Christiaan
I have searched the web for articles on how to create a custom membership and provider to move this to the DAL layer and have only find articles that do something simular for legacy programs. Is this not the right patht to go along anymmore?
-
I have searched the web for articles on how to create a custom membership and provider to move this to the DAL layer and have only find articles that do something simular for legacy programs. Is this not the right patht to go along anymmore?
DALs are still very popular and play a big role in n-Tier design. It's all about seperation of concerns/code maintenance: Your GUI code and your business logic code don't need to understand the database; they don't need to understand SQL, so abstract this kind of code. There are some really useful, really cool things in .Net but in my opinion, a few of them ignore good practice - putting connectionStrings in the application is one of them. However, it does depend on how scalable your application needs to be. If your app. consists of a couple of forms for a HR dept to add new staff, and isn't likely to grow much then I'd say...yeah...go with .Net Membership and don't concern yourself too much about design patterns, stick your db properties in the app.config/web.config. It's all about context really. What kind of application are you working on? Is this a team project or is it an app you're doing on your own? I'll see if I can find some detailed articles for you.
Mark Graham (MCP) blogging about Design Patterns, C#, Asp.Net, CSS, Javascript and Ajax at: DESIGN CODE TEST[^]
-
DALs are still very popular and play a big role in n-Tier design. It's all about seperation of concerns/code maintenance: Your GUI code and your business logic code don't need to understand the database; they don't need to understand SQL, so abstract this kind of code. There are some really useful, really cool things in .Net but in my opinion, a few of them ignore good practice - putting connectionStrings in the application is one of them. However, it does depend on how scalable your application needs to be. If your app. consists of a couple of forms for a HR dept to add new staff, and isn't likely to grow much then I'd say...yeah...go with .Net Membership and don't concern yourself too much about design patterns, stick your db properties in the app.config/web.config. It's all about context really. What kind of application are you working on? Is this a team project or is it an app you're doing on your own? I'll see if I can find some detailed articles for you.
Mark Graham (MCP) blogging about Design Patterns, C#, Asp.Net, CSS, Javascript and Ajax at: DESIGN CODE TEST[^]
Hi I agree that placing connection strings in the UI's config in not a very good practice to persue. My project currently is small and it is only me that develops it. But over time it can grew to a couple of 1000 users and we will have to get in other developers. The whole membership works cool with roles and everything. I will appreciate the articles. Thanks