I am using mongoDB that stores a simple product collection. I'm accessing this database from mongolab's API, so there is no direct access to the actual DB.
On the the other side, I have a Product model that has the same properties as the product document in the DB.
My question is: what design pattern(s) is(are) suitable in order to connect my business layer to the persistence layer.
So far I see these steps:
Product creation:
Create and populate the Product Model
Construct the endpoint URL for the API
Send request
Product retrieval:
Call methods like getProductByName() or getProductByCode()
Construct the endpoint URL for the API
Send request
Create and populate the Product Model based on the response.
I want to make the persistence layer as abstract as possible because in the future I might change the way I store and retrieve data. Also, this will be a simple application, so there is no need in using complicated logic or full ORMs.
Well I'm not an Android developer but I think my answer might be helpful. If your persistence layer is really simple and you are just going to have several methods there, there's no reason to complicate it with overdesign. Here's what I would do if I were you:
Add a new project to the solution for DAL layer.
Create a contract/interface with all methods you need.
Add all DTO's you might need to serve as input or output parameters for the methods.
Create a repository class which implements the interface. make sure it deals with all the API stuff (constructing the endpoint, etc.)
Reference the newly created library in your business layer. Make sure you use IoC to instantiate it. It's important you always reference the interface not the class itself.
Add some mapping logic between your business layer stuff and persistence layer DTO's
Now if you want to store your data in a database directly or whatever, you will need to create one more class which implements the interface and replace the old one. The rest of your code will remain untouched. Btw, it will be easy to mock the persistence layer for unit tests then.
Hope it helps.
Related
I have a Springboot Rest project. Suppose I have User class as entity. Is it ok to pass this entity object directly in the RequestBody of a POST method? My funcionality will work smoothly with this. My question is , whether it is a security flaw? If yes what is the solution?
This will work fine and is an easy implementation but architecturally this isn't a good practice because this tightly coupling your rest implementation with your database design and exposing it to the consumer of the API.
You should have request/response objects coming into your api and going out of it decoupling it from the database and allowing you to perform validations and other business rules at a layer above data access. If you find you are having to write a lot of assignment code between the entity and dtos then you can use a tool like http://modelmapper.org/ or http://mapstruct.org/
I need to retrieve a large graph of entities, manipulate it in the UI (adds, updates, deletes), then persist it all back to the database. After various SO questions and experiments, I'm finding this mass "detached graph update" approach to be very problematic, so I'm now rethinking my approach.
It's only a 2-tier WPF app, so I'm now thinking of having a long-running context that exists for the duration of the UI used to manipulate the entity graph - that way it can track changes automatically. However I'm not sure how to approach this architecturally.
The application currently has three projects - the UI, business tier, and one for the edmx & generated entities. My business tier has a CustomerManager class that exposes a method to retrieve a Customer graph (orders, order lines, etc.), and a method to persist the Customer graph. Assuming that the UI holds on to the same instance of the CustomerManager class, and therefore the same context, changes to the graph (adding and changing entities) will be tracked.
Deleting an entity is a bit more tricky, as the context must be used to do this, i.e.:-
context.Set<Order>().Remove(orderToDelete);
Looking for some architectural advice really. Do I just expose a DeleteOrder method in my CustomerManager class that does this? Given that I have a dozen other entity types, I would presumably need to expose similar methods to delete orders, products, etc.
Is it a sensible approach for the UI to hold on to the same CustomerManager instance, or is there a better way to manage a long-running context? A logical place for the DeleteOrder method would be in my Customer entity (partial) class, but as these classes are in a separate project from the business tier (which is where the context resides), I guess I can't do this (unless I pass the context to the DeleteOrder method)?
Your long living context idea will work only if your context lives in UI and UI talks to database directly to get and persist data. Involving WCF between your UI and context always result in serialization and it causes entity detaching = not tracking changes (unless you use STEs). Having long living context in WCF service is too problematic and in general bad practice.
Have you considered WCF Data Services? They provide client side tracking to some extend by using special client side context.
im doing some self-study on architecture of a MVVM-light - EF Application
im trying to build a product/Receipt like app.
I have a Db/EF with a Product and Receipt Table/Entity in a many to many relation.
then i have a DAL wich simply uses Linq to do simple CRUD.
the question is where and how to put my business logic in this app.
a couple of ideas came to mind
option 1
-make a ReceiptBo (Receipt business object)
wich inherit the Entity Receipt class and Icollection(ProductBo)
the ReceiptBo class would be responsible for adding Product,calculating total and subtotal and calling the Dal for inserting.
maby this option seemed a little overkill.
option 2
-put the calculating methods in the generated Entity objects by using partial classes
and simply using the BuisnessLayer to call the Dal.
this would make the Buisnesslayer Classes obsolete in my opinion and im not sure that Entity classes should be used for Business logic at all ?
option 3
-make the Business Classes but dont bother using inheritance, just add products to the Entity's and do the calculations there and call the Dal for insert.
wich seems simple but not very elegant.
option 4
-none of the above and im clueless
right now im not using WCF but the idea is that i want to make this app loosly coupled so that it would be easy to implement it and further extend it.
also im a little confused about what an Business layer is. in some examples it is more used like a Dal that also does the computing, then others say this is not done.
some help would be great. thx
ps: sorry for my bad english
Really, I would go simple here and choose a common multi-tier architecture designed as follows:
a data access layer (basically, your Entity Framework model along with all your entities)
a business layer that exposes methods to access to your entities (CRUD methods + any custom method that run some logic)
a service layer that exposes stateless methods through WCF (service+data contract)
the presentation layer (in your case using MVVM pattern)
Views (XAML pages)
ViewModels (C# classes)
Model is represented here by the entities that are exposed through WCF by the service layer
I wouldn't add any method directly in the entities. All methods are defined in the business layer, and exposed by the service layer.
Usually I keep my business logic in my ViewModels, not my Models, and I view EF objects as Models. At most, they'll have some basic data validation, such as verifying length or required fields.
For example, an EditRecieptViewModel would validate business rules such as verifying values are in a specific range, or verifying that users have access to edit the object, or performing some custom calculations when a value changes.
Also, don't forget that ViewModels should reflect the View, not a Model, so not every Model will have a ViewModel of its own
I have an ASP.NET MVC 2 application with some complex business rules and I'm trying to decide where to put specific logic.
The logic happens when creating records, based on certain fields of that record other records need to be created.
I'm currently using the repository pattern with an ORM and the easiest place to put this logic would be in my repository class but I feel like this is a pretty feeble location to have important rules, I would put it directly in my partial model classes that have my validation and metadata but I then have to call methods within my controller or repository and that may be extending too much knowledge about implementation to those layers.
What are your best practice tips for me?
Thanks!
You could have a service layer between the controller and the repositories. The repository performs simple CRUD operations with your model. A service method could make use of multiple simple repository calls to compose a business operation. This business operation will be exposed to the controller.
Our project manager has asked us to refactor an app that was using the Repository Pattern (it was done using Nerddinner as example) to now use a service Layer.
My problem now is that Im not sure how to Update a Model cause the UpdateModel method is supposed to be used in the controller... whats a recomended approach to updating a model using repository pattern along with a service layer??
please help
I would suggest you 'hide' your current Repository Pattern inside your service layer. Data access code should not be visible to the clients of the service.
You can implement a collection of DTOs that will be returned from service layer or accepted as parameters. Those objects can be just POCOs to hold the data in a database-agnostic way.
DTOs are usually accompanied by Adapters for translation to/from your data access classes (that represent tables). This approach allows you to change database schema without changing service layer interface.
You can treat those DTOs as models in MVC, if your project is simple and data for your views matches the service layer DTOs. You can also define your models in MVC project and let controller or another set of adapters translate models into DTOs.
My preferred design includes model that are declared in MVC (Models folder) that work with strongly-typed views. UpdateModel method then works with those classes. Next controller or ModelAdapter creates an instances of Service Layer DTOs and passes them to services. DTO adapters inside services are then responsible to populate data access classes from repository pattern.