Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would take issue with your first approach. I'm not sure that it makes sense that all of the separate business classes would somehow share the same interface for a <code>Delete</code> method. The parameters needed to delete a customer may not be the same as the parameters needed to delete an order. It seems odd to force them to share the same interface. Doing it that way may unnecessarily restrict the flexibility of your code in the future. Also, it seems odd that the business logic for deleting a customer would involve blindly looping through other objects, in no particular order, and calling a <code>Delete</code> method on all of them. I'd think you'd want to have more control over the order in which they get deleted and how it is handled when one of the delete methods fails.</p> <p>I would suggest first thinking of it at a higher level. What business methods do you actually need? Based on the scenario you described, I can see two business methods:</p> <ul> <li>Get a list of all the customers with no orders in the past 6 years</li> <li>Delete a customer (along with all of its orders)</li> </ul> <p>Since both of those methods are related to customers, it would make sense to group them together into a single customer business class, of some sort. For instance:</p> <pre><code>Public Interface ICustomerBusiness Function GetStaleCustomers(timeSinceLastOrder As TimeSpan) As IList(Of CustomerDto) Sub DeleteCustomer(customerId As Integer) End Interface </code></pre> <p>Once you've encapsulated the business logic like that, now it doesn't matter how the data access layer is implemented. The client makes calls to those simple business layer methods and doesn't have to care how the logic works behind the scenes. With the business logic encapsulated in its own layer, you will be free to rewrite it in different ways without having to rewrite any of your client code.</p> <p>So what would the logic inside that business class look like? It could be either a single call to a data access method that does all the work via one massive SQL command, or it could make many calls to do each step separately. That's really up to you. Obviously the former will be more efficient, but the latter will be more flexible. It will all depend on your needs. Here's a simple example of what each might look like:</p> <pre><code>Public Sub DeleteCustomer(id As Integer) _customerDataAccess.DeleteCustomerAndOrders(id) End Sub ' or... Public Sub DeleteCustomer(id As Integer) For Each i As OrderDto In _orderBusiness.GetOrdersByCustomer(id) _orderBusiness.DeleteOrder(i.Id) Next _customerDataAccess.DeleteCustomer(id) End Sub </code></pre> <p>The second option would be more flexible for multiple reasons. For instance:</p> <ul> <li>You would have finer control over what is happening and when. That would allow you to provide detailed status updates, if necessary, during the process. It would also allow you to provide detailed trace logging and more precise error messages when something fails. </li> <li>The business logic to delete orders would be broken out into a separate reusable business class. If you needed to delete just an order, from somewhere elsewhere in the code, you would be able to do so via common code.</li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POData Warehouse type solution?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USSteven Doggart
    1. USSteven Doggart
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POData Warehouse type solution?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COThanks. Could you explain what you mean by: "the latter will be more flexible" in the last paragraph?
      singulars
      1. PO
      1. USw0051977
    2. COI assume that you are talking about extensibility and all the benefits of a SOLID approach?
      singulars
      1. PO
      1. USw0051977
    3. CO@w0051977 I updated my answer to better describe what I meant by that.
      singulars
      1. PO
      1. USSteven Doggart
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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