Custom DAL

I don't know if this is the right forum section, so please re-direct me if not.

I was wondering about your comments on this. Would you consider this as a good DAL? Keep in mind, this is intended to handle only basic operations and is still under development, so, any comments are more than welcome ;)

Also, I made ID into a Decimal in TypeBase, because all my tables have a primary key in a form of a number. That's just a rule.

That design violates good practice because you are mixing the data itself with the classes used to manipulate that data. You are blatantly breaking the Single Responsibility Principle.

Also, record IDs should pretty much always be whole numbers, so Decimal is not really the most appropriate type. Long would be a better choice.

Quote:

---

Originally Posted by jmcilhinney

That design violates good practice because you are mixing the data itself with the classes used to manipulate that data.

---

Are you by any chance talking about the Business Logic Layer? If so, that's a separate issue. I know BLL is used to manipulate data, so, I use it on a different level.

The purpose was to make Data Access Layer to as most flexible and auto-generatable (if that's the word) state possible. I am really trying to follow the DAL - BLL - PLL guidelines.

Quote:

---

Originally Posted by jmcilhinney

You are blatantly breaking the Single Responsibility Principle.

---

Are you talking about "SelectRealValues"? It think that in some circumstances, too much classes is just too much to handle. Keep in mind, that a single DB can have up to 500 of this classes. If I break theme to 2 or 3, that's just too much. I think.

Btw... "SelectRealValues" is missing a "Optional List<SelectCondition>" :blush:

I'm talking about the fact that the same object is responsible for retrieving data and storing that data. The object that retrieves the data should then be storing that data in some other object. You've also got that same object aware of navigation within that data. It's just too many things all piled into the same class.

Think about the VB6 Recordset and then think about how you do the same thing in .NET. You have separate classes for connecting to the database, executing the SQL command, reading the result set and storing the data. That's an example of the Single Responsibility Principle at work.