i am trying to implement repository pattern in mvc. but I am stuck. I want to return related data. I have two classes , tbl_Account (contains users )and tbl_Country (contains countries).
public class AccountRepository : IAccount
{
public IEnumerable<Account> GetCountry()
{
var Account = this.storeDB.tbl_UserAccount.Include(s => s.tbl_Country).ToList();
return Account; // it gives error here, saying explicit cast required
}
}
Account is a model class i have created on top of tbl_Account for field validations.
how to cast this or i am missing something else... please please help
1.) Variable name must start lower case.
2.) Method name 'GetCountry' but you return Account.
3.) After include you need to Select countries in account and then return countries.
4.) Please share your entities (model classes) in your question if you wanna get cool answers
please excuse the long description at the beginning. the questions are at the end.
i have a windows service that is supposed to read data form some data sources (represented by the IDataSource interface).
i'm using MEF in my project and i was thinking of injecting the required data sources via ctor injection like below:
[Export(typeof(Service))]
public class Service:ServiceBase{
[ImportingConstructor]
public Service([ImportMany]IEnumerable<IDataSource> dataSources){
//...
}
}
However, there is a problem in doing it like this. The service needs to use any combination of data sources: multiple data sources of the same type (ex: 2 CSVDataSource instances) or multiple data sources of different types (ex: 2 CSVDataSource instances and 1 SQLDataSource instance).
Each data source has properties that are retrieved from the DB in order to properly set it up. these settings might indicate from where to read the data and at what intervals. this is why, in my implementation, the data sources have a ctor that accepts an id. this id is used to identify the data source in the DB and to retrieve the specific data source settings from the DB. this can be seen below.
public class CSVDataSource: IDataSource{
public CSVDataSource(int dsId){
//call web service in order to get properties to
//properly set up the data source.
}
//...
}
i feel that the service definition presented above is not suited for this scenario. The other approach I can think of is to use some sort of factory that allows the service to dynamically create the data sources inside. this implementation might look like below.
public class Service:ServiceBase{
[ImportingConstructor]
public Service(IDataSourceFactory dsFactory)
{
if (dsFactory == null) throw new ArgumentNullException("dsFactory");
IEnumerable<IDataSource> dataSources = dsFactory.CreateAll();
}
}
[Export(typeof(IDataSourceFactory))]
[PartCreationPolicy(CreationPolicy.Shared)]
public class DataSourceFactory:IDataSourceFactory
{
private readonly int agentId;
[ImportingConstructor]
public DataSourceFactory([Import("AgentId")]int agentId)
{
this.agentId = agentId;
}
public IEnumerable<IDataSource> CreateAll()
{
List<IDataSource> dataSources = new List<IDataSource>();
//access web service and instantiate the data sources
return dataSources;
}
}
And now to my questions:
is my factory approach a good ideea or should i look for another approach?
is it ok to have exports that require data from a remote location in order to be created?
Did you come across ExportMetadataAttribute before? It will allow you to assign metadata to an export that you can view before the export is created. You'll be able to import your IDataSources as Lazy and then should be able to create them yourself with the required parameters.
There's a good breakdown of Lazy and ExportMetadata here
I have a web api project that I'm building on an N-Tier system. Without causing too many changes to the overall system, I will not be touching the data server that has access to the database. Instead, I'm using .NET remoting to create a tcp channel that will allow me to send requests to the data server, which will then query the database and send back a response object.
On my application, I would like to use entity framework to create my datacontexts (unit of work), then create a repository pattern that interfaces with those contexts, which will be called by the web api project that I created.
However, I'm having problems with entity framework as it requires me to have a connection with the database. Is there anyway I can create a full entity framework project without any sqlconnections to the database? I just need dbcontexts, which I will be mapping my response objects and I figure that EF would do what I needed (ie help with design, and team collabs, and provide a nice graphical designer); but it throws an error insisting that I need a connection string.
I've been searching high and low for tutorials where a database is not needed, nor any sql connection string (this means no localdb either).
Okay as promised, I have 3 solutions for this. I personally went with #3.
Note: Whenever there is a repository pattern present, and "datacontext" is used, this is interpreted as your UnitOfWork.
Solution 1: Create singletons to represent your datacontext.
http://www.breezejs.com/samples/nodb
I found this idea after going to BreezeJS.com's website and checked out their samples. They have a sample called NoDb, which allows them to create a singleton, which can create an item and a list of items, and a method to populate the datacontext. You create singletons that would lock a space in memory to prevent any kind of thread conflicts. Here is a tid bit of the code:
//generates singleton
public class TodoContext
{
static TodoContext{ }
private TodoContext() { }
public static TodoContext Instance
{
get
{
if (!__instance._initialized)
{
__instance.PopulateWithSampleData();
__instance._initialized = true;
}
return __instance;
}
}
public void PopulateWithSampleData()
{
var newList = new TodoItem { Title = "Before work"};
AddTodoList(newList);
var listId = newList.TodoListId;
var newItem = new TodoItem {
TodoListId = listId, Title = "Make coffee", IsDone = false };
AddTodoItem(newItem);
newItem = new TodoItem {
TodoListId = listId, Title = "Turn heater off", IsDone = false };
AddTodoItem(newItem);
}
//SaveChanges(), SaveTodoList(), AddTodoItem, etc.
{ ... }
private static readonly Object __lock = new Object();
private static readonly TodoContext __instance = new TodoContext();
private bool _initialized;
private readonly List<TodoItem> _todoLists = new List<TodoItem>();
private readonly List<KeyMapping> _keyMappings = new List<KeyMapping>();
}
There's a repository included which directs how to save the context and what needs to be done before the context is saved. It also allows the list of items to be queryable.
Problem I had with this:
I felt like there was higher maintenance when creating new datacontexts. If I have StateContext, CityContext, CountryContext, the overhead of creating them would be too great. I'd have problems trying to wrap my head around relating them to each other as well. Plus I'm not too sure how many people out there who agree with using singletons. I've read articles that we should avoid singletons at all costs. I'm more concerns about anyone who'd be reading this much code.
Solution 2: Override the Seed() for DropCreateDatabaseAlways
http://www.itorian.com/2012/10/entity-frameworks-database-seed-method.html
For this trick, you have to create a class called SampleDatastoreInitializer that inherits from System.Data.Entity.DropCreateDatabaseAlways where T is the datacontext, which has a reference to a collection of your POCO model.
public class State
{
[Key()]
public string Abbr{ get; set; }
public string Name{ get; set; }
}
public class StateContext : DbContext
{
public virtual IDbSet<State> States { get; set; }
}
public class SampleDatastoreInitializer : DropCreateDatabaseAlways<StateContext>
{
protected override void Seed (StateContext context)
{
var states = new List<State>
{
new State { Abbr = "NY", Name = "New York" },
new State { Abbr = "CA", Name = "California" },
new State { Abbr = "AL", Name = "Alabama" },
new State { Abbr = "Tx", Name = "Texas" },
};
states.ForEach(s => context.States.Add(s));
context.SaveChanges();
}
}
This will actually embed the data in a cache, the DropCreateDatabaseAlways means that it will drop the cache and recreate it no matter what. If you use some other means of IDatabaseInitializer, and your model has a unique key, you might get an exception error, where you run it the first time, it works, but run it again and again, it will fail because you're violating the constraints of primary key (since you're adding duplicate rows).
Problem I had with this:
This seems like it should only be used to provide sample data when you're testing the application, not for production level. Plus I'd have to continously create a new initializer for each context, which plays a similar problem noted in solution 1 of maintainability. There is nothing automatic happening here. But if you want a way to inject sample code without hooking up to a database, this is a great solution.
Solution 3: Entity framework with Repository (In-memory persistence)
I got this solution from this website:
http://www.roelvanlisdonk.nl/?p=2827
He first sets up an edmx file, using EF5 and the code generator templates for EF5 dbcontexts you can get from VS extension libraries.
He first uses the edmx to create the contexts and changes the tt templates to bind to the repository class he made, so that the repository will keep track of the datacontext, and provide the options of querying and accessing the data through the repository; in his website though he calls the repository as MemoryPersistenceDbSet.
The templates he modified will be used to create datacontexts that will bind to an interface (IEntity) shared by all. Doing it this way is nice because you are establishing a Dependency Injection, so that you can add any entity you want through the T4 templates, and there'd be no complaints.
Advantage of this solution:
Wrapping up the edmx in repository pattern allows you to leverage the n-tier architecture, so that any changes done to the backend won't affect the front end, and allows you to separate the interface between the front end and backend so there are no coupled dependencies. So maybe later on, I can replace my edmx with petapoco, or massive, or some other ORM, or switch from in-memory persistence to fetching data from a database.
I followed everything exactly as explained. I made one modification though:
In the t4 template for .Context.tt, where DbSetInConstructor is added, I had the code written like this:
public string DbSetInConstructor(EntitySet entitySet)
{
return string.Format(
CultureInfo.InvariantCulture,
“this.{1} = new BaseRepository();”,
_typeMapper.GetTypeName(entitySet.ElementType), entitySet);
}
Because in my case I had the entityset = Persons and entityname = Person. So there’d be discrepancy. But this should cover all bases.
Final step:
So whether you picked solution 1, 2, or 3. You have a method to automatically populate your application. In these cases, the stubs are embedded in the code. In my case, what I've done is have my web server (containing my front end app), contact my data server, have the data server query the database. The data server will receive a dataset, serialize it, and pass it back to the web server. The web server will take that dataset, deserialize it, and auto-map to an object collection (list, or enumberable, or objectcollection, etc).
I would post the solutions more fully but there's way too much detail between all 3 of these solutions. Hopefully these solutions would point anyone in the right direction.
Dependency Injection
If anyone wants some information about how to allow DI to api controllers, Peter Provost provides a very useful blog that explains how to do it. He does a very very good job.
http://www.peterprovost.org/blog/2012/06/19/adding-ninject-to-web-api/
few more helpful links of repository wrapping up edmx:
http://blogs.msdn.com/b/wriju/archive/2013/08/23/using-repository-pattern-in-entity-framework.aspx
http://www.codeproject.com/Articles/688929/Repository-Pattern-and-Unit-of
I created an extension with a domain model Message. This model has a relation m:n with the TYPO3 pages (the one which has the details of the pages, like title, issite_root etc) table. However, by using the mapping to existing tables option, it gives me type error saying page :
The configured type field for table "pages" is of type int(11) unsigned
This means the type field can not be used for defining the record type.
You have to configure the mappings yourself if you want to map to this
table or extend the correlated class
So I just create the relation without mapping, so that I can later map it from setup.txt.
The I created model Pages in MyExt/Classes/Domain/Model/ with all the getters/setters and repository in MyExt/Classes/Domain/Repository/.
In my setup.txt I did this:
config.tx_extbase {
persistence{
enableAutomaticCacheClearing = 1
updateReferenceIndex = 0
classes {
Tx_Playfield_Domain_Model_Pages {
mapping {
tableName = pages
columns {
uid.mapOnProperty = uid
pid.mapOnProperty = pid
sorting.mapOnProperty = sorting
title.mapOnProperty = title
subtitle.mapOnProperty = subtitle
}
}
}
}
}
}
But when I try to access the Pages model I created,
var_dump($this->pagesRepository->findByUid(74));
its searching for tx_playfield_domain_model_pages which does not exists, it shows
Table 'typo3.tx_playfield_domain_model_pages' doesn't exist: SELECT tx_playfield_domain_model_pages.* FROM tx_playfield_domain_model_pages WHERE tx_playfield_domain_model_pages.uid = '74' LIMIT 1
What am I missing here?
Update
After following http://t3-developer.com/extbase-fluid/cheats-extbase/model/tabelle-pages-in-extbase/ suggested by #Michael I get an empty result from $this->pagesRepository->findByUid(74)
setup.txt is loading. I did this to check it:
plugin.tx_playfield{
settings{
temp=yes
}
}
And this is being accessed from my controller.
Is it possible that you didn't create the Pages domain model (within the extension builder or not at all)? The file my_ext/Classes/Domain/Model/Pages.php needs to exist. Check that your "Pages" domain model has the property Map to existing table set to pages, it should look like that:
I don't know where exactly your error is, but I did some more tinkering in the extension builder and made it work. You can probably find out by comparing your extension playfield to my temporary extension testfield: Download it here (updated).
Btw, you don't need to map properties that you do not want to be displayed in the frontend unless they are named differently.
mapping {
tableName = pages
columns {
title.mapOnProperty = title
subtitle.mapOnProperty = subtitle
}
}
I think you have to write the mapping with camel case letters (the class name). Although this post is in German, I think the code might help you. The author added some fields he is going to use to the class and also added a mapping in the typoscript of the extension (see the example code there). The most important part of the German text is that this example there was designed only to read from the db. If you want to create new pages using the model, you have (at least) to add the TCA and setters in the model class to make it work.
I'm using AutoMapper to map between a Linq Domain object and a ViewModel to display an Edit Form to the user which works perfectly.
When they click submit I'd like to know the best way to map the ViewModel back to a Linq entity and persist it to the database.
The Linq entity I'm using has multiple collections of other entities (ie one-to-many references).
I was trying:
build up my custom view model using UpdateModel
get the previous state of the Linq entity by using the passed in id
map the view model onto the Linq entity (using automapper)
call SubmitChanges() on the data context
This method works when I'm only updating properties that are not collections, but throws errors when trying to modify properties that are collections.
Any help/thoughts would be much appreciated :)
I've taken an approach that is very similar to that used by Jimmy Bogard in the CodeCampServer project (http://codecampserver.codeplex.com/)
I have a general Mapper class that I inherit from where I just need to override a MapToModel method that maps from the ViewModel to the domain Model, and a GetIdFromViewModel method that returns the proper Id form the ViewModel so that the Service layer can grab the domain model from the database.
I had to change a little from the CodeCampServer examples because some of my Models used Guid and some used int as the Id for the Model.
You should be able to grab the code from the codeplex link above and that should help get you going in that direction.
Here is what one of my Mappers for a Member looks like:
public class MemberMapper : AutoFormMapper<Member, MemberFormViewModel, Guid>, IMemberMapper
{
public MemberMapper(IMemberService service) : base(service) { }
protected override Guid GetIdFromViewModel(MemberFormViewModel viewModel)
{
return viewModel.MemberId;
}
protected override void MapToModel(MemberFormViewModel viewModel, Member model)
{
// if the need arises, we will need to map the full objects as Foreign Key properties
// by using the proper repositories
// right now for loading the object to save back to the DB we don't have that need, so let's not waste the call
model.MemberId = viewModel.MemberId;
model.FirstName = viewModel.FirstName;
model.LastName = viewModel.LastName;
model.Title = viewModel.Title;
model.EmailAddress = viewModel.EmailAddress;
model.DirectPhone = viewModel.DirectPhone;
model.MobilePhone = viewModel.MobilePhone;
model.ElectronicId = viewModel.ElectronicId;
model.ProjectRoleTypeId = viewModel.ProjectRoleTypeId;
model.DepartmentId = viewModel.DepartmentId;
}
}
Then you can use this MemberMapper to map both directions. It uses AutoMapper to go from the domain Model to the View Model and then uses the MapToModel method that you implement to map from the View Model back to the domain Model.