I’ve been studying n-tier architectures as of late, particularly in VB.NET with Entity Framework and/or LINQ to SQL. I understand the basic concepts, but have been wondering about best practices in regard to triggering CRUD-type operations from user input/action. So, the arcitecture looks something like the following:
[presentation layer] -> [business layer] -> [data layer] -> (database)
Getting information from the database into the presentation layer is simple and abstracted. It’s just a matter of instantiating a new object from the business layer, which in turn uses the data layer to get at the correct information. However, saving (updating and inserting), and deleting seem to require particular APIs on the relevant business objects. I have to assume this is standard practice, unless a business object will save itself on various operations (which seems inefficient), or on disposal (which seems like it just wouldn’t work, or may be unwieldy and unreliable).
Should my “savable” business objects all implement a particular “ISavable” or “IDatabaseObject” interface? Is this a recognized (anti-)pattern? Are there other, better patterns I should be using that I’m just unaware of?
The TLDR question, I suppose, is How does the presentation layer trigger database changes?
How does the presentation layer trigger database changes?
Well, presentation layer should not directly trigger changes in database layer. It should initiate call to the service layer, where your business logic should verify the request. Upon successful verification it should perform DB operation on entities/tables that it needs.
You may also look at this very useful pattern – Repository Pattern that may associate a behavior with the related data.
3