StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The sort of layering you're trying for usually involves moving away from the DataTable approach to something that uses an instance for (roughly) each row in the database. In other words, the DAL would return either a single User or a collection of Users, depending on which static Load method you call. This means that all of the methods that take a bunch of parameters to represent the user would instead accept a User DTO.</p> <p>A DAL for users would look something like this:</p> <pre><code>public static class UserDal { public static User Load(int id) { } public static User Save(User user) } { } public static IEnumerable<User> LoadByDiv(int divId) { } } </code></pre> <ol> <li><p>It's static because it has no state. (Arguably, it could have a database connection as its state, but that's not a good idea in most cases, and connection pooling removes any benefit. Others might argue for a singleton pattern.)</p></li> <li><p>It operates at the level of the User DTO class, not DataTable or any other database-specific abstraction. Perhaps the implementation uses a database, perhaps it uses LINQ: the caller need not know either way. Note how it returns an IEnumerable rather than committing to any particular sort of collection.</p></li> <li><p>It is concerned only with data access, not business rules. Therefore, it should be callable only from within a business logic class that deals with users. Such a class can decide what level of access the caller is permitted to have, if any.</p></li> <li><p>DTO stands for Data Transfer Object, which usually amounts to a class containing just public properties. It may well have a dirty flag that is automatically set when properties are changed. There may be a way to explictly set the dirty flag, but no public way to clear it. Also, the ID is typically read-only (so that it can only be filled in from deserialization).</p></li> <li><p>The DTO intentionally does not contain business logic that attempts to ensure correctness; instead, the corresponding business logic class is what contextually enforces rules. Business logic changes, so if the DTO or DAL were burdened with it, the violation of the single responsibility principle would lead to disasters such as not being able to deserialize an object because its values are no longer considered legal.</p></li> <li><p>The presentation layer can instantiate a User object, fill it in and ask the business logic layer to please call the Save method in the DAL. If the BLL chooses to do this, it will fill in the ID and clear the dirty flag. Using this ID, the BLL can then retrieve persisted instances by calling the DAL's Load-by-ID method.</p></li> <li><p>The DAL always has a Save method and a Load-by-ID method, but it may well have query-based load methods, such as the LoadByDiv example above. It needs to offer whatever methods the BLL requires for efficient operation.</p></li> <li><p>The implementation of the DAL is a secret as far as the BLL and above are concerned. If the backing is a database, there would typically be stored procedures corresponding to the various DAL methods, but this is an implementation detail. In the same way, so is any sort of caching.</p></li> </ol>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload