How and where do you create the repository object in your android apps?
Do you implement your repository as a singletone? Is it a static class?
I am trying to use the single activity approach:
Apparently I wanna use the same repository in each ViewModel. But what approach do you chose or which one makes more sense to have your repository existing just once and having acces to it from everywhere?
In the android developer examples they create the repository object in the mainactivity because they need the application object to create the repository. But in this example you cannot acces it from everywhere and you could create multiple for the same reason, e.g. handling SQL.
Did you read this guide, Guide to app architecture? I think this would answer most of your questions.
Actually you shouldn't access repository from everywhere, but from the ViewModels or even better from UseCases (Domain layer, have a look on Clean Architecture).
ViewModel delegates the data-fetching process to a new module, a repository. Repository modules handle data operations. They provide a clean API so that the rest of the app can retrieve this data easily. They know where to get the data from and what API calls to make when data is updated. You can consider repositories to be mediators between different data sources, such as persistent models, web services, and caches.
and to manage dependencies between components you can use some DI libraries.
Related
It happens to me that I was suggested to use repository patterns in MVC for my project. I know it puts some extra security in or project but is there any other benefit of changing the project's structure to repository patterns.
Repository pattern gives an abstraction of the data layer. So that before your classes will get something from model - there is layer of repository.
Let's say that repository is agent between your controller (or other classes) and models. It is up to developer if need this kind of layer or not.
In my opinion it is good practice to use repositories. I do not want to make direct operations in models. Repository can have extra functions or overwrite some model functions. Then in your controller you send requests to repository, not to model.
When you work with Symfony Framework, you will see that they implement this Repository Pattern by default.
I have created Business and DataAccess Layer for my web project using dotnet core.
I have added Data access reference in Business layer and referenced the business layer in UI (web project) layer.
I seen, I am able to access my Data access layer from my UI (web) project. I am really wondering, It can lead to violation of any application design.
Appreciate help, if anybody come across this and how to restrict access to data access layer from UI.
Yes, an indirect dependency is a dependency too.
And your toplevel (MVC) project has to reference everything, direct or indirect, in order to get all modules loaded. And to set up the dependency injection.
You can get better separation by introducing an interfaces layer in a separate project. For example IBusinessClass and IDataAccessClass.
That works for everything but the main project so if you want this particular separation from your example, move your Controllers to a separate project and depend that on the IBusiness interfaces only. Though I'm not sure how that works with MVC's conventions.
I've been checking quite a few examples related to Web Api, and they all create the model in the Models folder contained with the Web Api project but I'm curious as to how this should be handled if you want to use/re-use these models with various projects.
In the past, when using WCF REST, I would have created the following:
Business Model Project (PCL)
Business Layer Project
Data Layer Project
SQL Data Layer Project
WCF REST Project
Web App
Windows App
Third-Party Web app (javascript)
Mobile App (Xamarin)
Projects 2 to 9 would have all been referenced to Project 1 or objects would be created dynamically when using JavaScript. The business object project only contained POCO objects, most decorated with DataContract/DataMember attributes.
Can the same logic/Project breakdown be applied when using Web Api? Is it recommended or will I face problem at a later stage?
If it's not recommended, am I suppose to duplicate all my models? Doesn't seem to make sense so I thought I'd ask.
Thanks.
Short answer, YES. The same logic/Project breakdown can be applied when using Web Api. This is also how I implement my architecture. Your Web Api would just be another layer in your architecture. By doing it that way you will allow for greater re-usability of the models (DRY) and maintainability.
I am using unity 2.0 with MVC3 and need some help understanding the LifeTimeManagers. I have read a lot of people using a custom LifeTimeManager that places items into the HTTPContext. This makes perfect sense because you only want the UoW around for the lifetime of the request in MVC. However, do I need the same lifetime manager for my repositories and services? I was looking at this post and noticed the same lifetime manager for the UoW, repositories, and services.
My Repositories depend on a UoW, and my Services depend on the Repositories. I am not sure what Unity does, by default, regarding a lifetime manager, but I did create a custom HttpContext manager and have had issues with it just being on the UoW. I have not put it on any of my services or repositories yet. I am wondering if I need to or if that is the best practice.
Simply use the Nuget package for unity.mvc3 and it contains a hierarchicallifetimemanager. When you register the types that need to be disposed in your mappings, it will dispose them.
DOn't worry about doing anything directly with httpcontext, this is far easier.
See the section on
IDisposable dependencies
http://www.devtrends.co.uk/blog/integrating-the-unity.mvc3-1.1-nuget-package-from-scratch
For anything you want disposed explicitly (that implements IDisposable) use this lifetime manager:
container.RegisterType(new HierarchicalLifetimeManager());
I am creating my first ASP.NET MVC 3 application, and my data comes from a data source I can access only via its REST API.
I will only be using READ-ONLY access at this point to the REST data source (no updating, etc.)
I would like to use the Entity Framework V4 to provide a Business Entity interface to MVC 3 without exposing it to the REST API.
I need to get something working quickly - so I don't have time to fully understand the Server Layer / UnitOfWork and Repository patterns just yet, although I plan to go there next.
I am willing to use a Repository class at this time, but not ready for DI / IoC container yet.
Any suggestions on where the RESP API calls go?
EDIT
Learned by asking this question that it is not necessarily useful to integrate an ORM with a REST API - See my accepted answer below.
An Object/Relational Mapper, or ORM, like Entity Framework has specifically been developed to abstract away a relational database. It might not be the right fit for REST calls.
You could instead build a repository class that encapsulates the REST call and exposes methods like IEnumerable<T> GetAll() or T GetyById(...).