ADO.NET :: Trying To Create A Data Repository And Using L2S For The ORM?
Feb 7, 2011
i am trying to create a data repository and i am using L2S for the ORM.
I have created a stored procedure called sp7DayAnalysisByStock which accepts a string parameter and returns a recordset of data rows. iThe result is a set of PriceList objects which is already available in the dbml.
What i now want to is create a data repository class with the signature below;
public IQueryable<PriceLists> Get7DayStockAnalysis(string stockname)
{
}
it seems what is being returned is ISingleResult..How can i return EITHER IQueryable<PriceLists> or any IList?
I am trying to create a repository class for each table. For example I have TableA, TableB and TableC. TableB and TableC has Foreign key to TableA. I created an interface for TableA, TableB and TableC with SaveData() and ListData(). I have MVC form which inserts the data into these tables. When implementing these interface methods do I have to create a seperate class for each interface? Please let me if I am doing right.
I'm working on using the Repository methodology in my App and I have a very fundamental question.When I build my Model, I have a Data.dbml file and then I'm putting my Repositories in the same folder with it.... IE:
Data.dbml IUserRepository.cs UserRepository.cs
Is it better to build the folder structure like that above, or is it ok to simply put my Interface in with the UserRepository.cs?
I have built my first MVC solution and used the repository pattern for retrieving/inserting/updating my database.
I am now in the process of refactoring and I've noticed that a lot of (in fact all) the methods within my repository are hitting the database everytime. This seems overkill and what I'd ideally like is to do is 'cache' the main data object e.g. 'GetAllAdverts' from the database and to then query against this cached object for things like 'FindAdvert(id), AddAdvert(), DeleteAdvert() etc..'
I'd also need to consider updating/deleting/adding records to this cache object and the database.
What is the best apporoach for something like this?
My knowledge of this type of things is minimal and really looking for advice/guidance/tutorial to point me in the right direction.
I am currently using the 3-tier Repository pattern in my application. Actually it's the first time for me to implement a design pattern at all! i used to put all my code in the so called now presentation layer.
i want to implement data validation, for example, password should not be more than 10 characters and have to contain special characters. Should i put this code in the data access layer? but my data access layer contains methods that take the DTO as a parameter for example
[Code]....
and the same is for other CRUD operations (DELETE and UPDATE), so implementing such validation on the DAL would make me duplicate the code in each and every method that accepts the DataObject as a paramter. Same holds for the business logic layer where i am using it as a proxy between the presentation and the data access layers.
Eventually it has to use the same Data Objects as parameters. This only leaves me with one option which is to do the validation on the Data Object part. But i think this is not the essence of the respository pattern which states that the Data object class should only be a "container" class with no behavior.
I am new to MVC and this really probably should not be posted here but in a different forum topic. The reason I am posting here though is I am not sure if there is something about MVC that would prevent me from doing what I am looking to do.So here it goes.Maybe I am the only one out there that thinks this way but I don't care for and don't fully understand LINQ. I Like building my stored procedures passing my data to a datareader etc... and displaying what I need.
Now that being said I am wanting to learn how to make a true Data Repository and build from there but everything I find online especially here all gives me examples and instructions on how to do so using LINQ.Does anyone know of a site that will teach me how to do this without using LINQ or any form of ORM just allow me to write my stored procs how they need to be and build my classes for data access how they need to be.I may be wrong in this but it seems to me this would be the more light weight way of doing it.Anyhow as stated above the additional question to this would be is there any reason this would not work for MVC and actually any reason it is extremely (or at least for me) hard to find any documentation on this anywhere online?
Just wondering, in an ASP.NET MVC3 environnement with entity framework. Should the Unit of Work point to the service layer or the repository (and then the repository point to the service layer) ?
Ive saw two example:
* One where the unit of work and repository both have an instance to the service layer..
Link: Entity Framework 4 CTP 4 / CTP 5 Generic Repository Pattern and Unit Testable
Doesn't use a service layer but its obvious that one could be use in that case.
* Second where the unit of work have an instance to the repository which have an instance to the service layer..
We are moving from ASP.NET Web Forms to MVC 2.0. In most of our projects we have a typical setup to communicate with a database.
Common (objects/entities like 'SiteMenu' and 'Users')
Business Logic Layer (with calls to de Data Access Layer)
Data Access Layer
The DAL has a DatabaseHelper with common database operation, an OdbcHelper with database specific operations (eg MySQL) and a StoredProcedure class with all the stored procedures.
How is this design translated into a repository design? We want to use our own database helpers instead of NHibernate etc.
i'm new to asp.net MVC, and I'm trying to understand the service/repository pattern and how to best implement it.
I've followed the MVC Music store tutorial, and it suggests that the public partial class ShoppingCart implements an AddToCart method looking like this:
[Code]....
Now if I would like to use the service/repository pattern in a correct way, should I just replace the row "storeDB.AddToCarts(cartItem)" with something like cartService.AddToCarts(cartItem) and then just save the added row by calling cartService.Save() instead of shopDB.Save()? The methods AddToCart(...) and Save() in cartService then calls the repository that does the actual saving.
In a typical business application, a session is started and persisted across several pages. It is commited only when the transaction is complete. A good example of this is a tax preparation application. Once the session is started, it is persisted through session, cookies, or both. Nothing is written to file, or database, until the entire profile is complete and the refund/return is calculated. In such an ennvironment, is makes a great deal of sense to work with the structure imposed by domain driven design, and using a single repository to simple commit the session. However, there are times when this doesn't translate correctly, even when domain driven design is used.
An example of this is my forum project. While the entities themselves are good targets for domain driven design, I am not sure about the repositories. The basic structure is that a Category has many Forums, a Forum has many Threads, and a Thread has many posts. There are other things in there, but that's enough to describe what I want to get across. If a user has navigated to /Thread/Edit/42, and they have rights to edit it, all I am concerned about is fetching that record and displaying it. On postback, all I want is to be able to save it..................
I've been using MVC for the last year and unfortunately I am stuck adding features to an existing web forms site. The site makes heavy use of inline SQL and it is kind of all over the place. Using an ORM is not going to happen either and wouldn't address the problem of keeping queries all in one place.
Can the Repository Pattern and Service layers also work well with classic asp.net web forms?
I am building an application using asp.net mvc, DI, IoC, TDD as a bit of a learning exercise.
For my data access I am using the repository pattern. Now I am looking at membership and how this can work with the repository pattern. I am currently using a Linq to Sql repository but don't want to be tied to SQL Server for membership.
Secondly, I am looking to split out membership into a number of services:
AuthenticationService - identify the user AuthorizationService - what can they do PersonalizationService - profile
The personalization service will be what really defines a "customer" in my application and each customer will have a unique id/username that ties back to the AuthenticationService - thus, allowing me to use the default ASP.NET Membership provider, roll my own or use something like Open ID.
Is this a good approach? I don't want to reinvent the wheel but would rather these important parts of my application follow the same patterns as the rest.
I need some guidance for an application I am working on. I have searched the web and the forum and found parts that answer my questions but I want to do this correctly. My solution uses LINQ to SQL to model the db and I have a repository that is querying my db everytime a controller needs to get some data for the view. I am initially anticipating a maximum of only about a few hundreds hits per day (if that). The website is a directory, with listings and requires a search functionality.
1. What options should I consider to avoid having my repository query the db everytime
2. The site contains a 'search' option, how can I implement this against my repository?
I guess I'm really looking for someone to point me in the right direction. So far I've looked at 'caching' the LINQ to SQL model and Lucene.NET but both seem overkill or am I missing the point?
I am sort of using a repository pattern to extract information from a database. I have two classes, report and reportRepository.
The trouble I have is that since reportReposity has to fill in all the details for the report object, all the members in the report have to be publicly accessible.
Is there a way so that I can ensure that only the repository class can access some of the methods of the report class and only it can set some of the properties that other classes cannot, sort of like what friend does in c++. Or is there a completely different way of handling this situation?
I'm having problems with getting my custom dataannotations to work, I'm trying to add a validation-attribute that validates that the UsergroupName for a Customer (CustomerID) is unique.
[Code]....
the IsValid should return false if the "count >0". How do I fix this one so it works. GetUsergroups() returns IQueryable<Usergroup>.
I have a question that I'm ashamed to ask, but I'm going to have a go at it anyway. I am creating a generic repository in asp.net mvc. I came across an example on this website which I find to be exactly what I was looking for, but there is one problem. It references an object - Entity - and I don't know what namespace it is in. I typically create my repositories and use Entity Framework but I decided to use a generic repository because I am using the same code in multiple projects over and over again.
Here is the code:
public interface IRepository { void Save(ENTITY entity) where ENTITY : Entity; void Delete<ENTITY>(ENTITY entity) where ENTITY : Entity;
[code]....
what namespace Entity is in? As you can tell, a constraint is placed on the code so that it must be an Entity type. I know that there is an Entity in System.Data.Entity, but that isn't what I need. I have had instances before where I was looking for some namespace that took me forever to find, but I have searched and I'm unable to find the appropriate namespace to cast my generic items correctly. I could cast it as a class and be done with it, but it is bugging me that I can't find Entity anywhere.
We have many applications. All the applications are having there one access control. I am planning to build a central access control repository. All the application should refer this repository for access (We can say it one point contact). What are the things needs to be taken into consideration and what the approach that we need to follow?
I'm using asp.net and WebDeploy to publish the latest bits of my website. The production site has a couple folders that I would like to keep in sync, though.
Since it's an asp.net site, I would rather not have my entire repository on the server when I can get by with just the views and dll. Additionally, I would rather not add the extra clutter of additional class projects & files to my production server file system.
How do I keep the folders in production in sync with the master branch in git? An automated solution would be optimal.
In an ASP.NET MVC3 environnement with entity framework. Should the Unit of Work point to the service layer or the repository (and then the repository point to the service layer) ?
Ive saw two example:
* One where the unit of work and repository both have an instance to the service layer..
Link: Entity Framework 4 CTP 4 / CTP 5 Generic Repository Pattern and Unit Testable
Doesn't use a service layer but its obvious that one could be use in that case.
* Second where the unit of work have an instance to the repository which have an instance to the service layer..
I am working on a project. Completed conceptual model of Database is done in EntityFrameWork. Database is not created yet. Should I make a dummy Records with dummy repository and go on development without creating database and once all done than just created the DB and turn dummy repositories to live? . Is it right decision or should I start making database to work with it from the start?
This is possibly the worst kind of religious debate -- a religious debate with practical consequences. But it's one that needs to be had, and I can't seem to fit it in my tiny head. Here are the pros and cons of the pattern as I know them:
Pros:
-Encourages DRY (don't repeat yourself) design in that identical queries are written only once per set of query conditions -Facilitates unit testing by allowing itself to be abstracted into an interface -Creates an opportunity for business-level validation
Cons:
-Breaks DRY philosophy in that you're generally repeating your database schema -In a sense breaks separation of concerns, because the query concerns of the controller and view frequently become the concerns of whoever is maintaining the repository -Determining what should be a repository and what should be returned as a raw associated ORM entity becomes an ambiguous art
To me it seems like all this stuff should be done at the ORM level, but Entity Framework has much fewer hooks than Linq to Sql does, yet Entity Framework tends to be regarded as being more robust, so it seems that this is by design, and that the designers of EF are in fact encouraging another layer. Are there any tools or anything that I could be using for this? Am I missing something?
I've been reading recently about EF4, and how to build an architecture for asp.net web forms application using it.
I explored using POCOs (self tracking entities), with WCF, but found out that my application will be deployed on a single box (i.e. one tier), so I started reading about logical separation of layers, and came up with the following solution:
DAL layer that contains EDMX model and EF APIs, and also generated context object.Entities DLL that holds all generated POCO entities using ADO.NET POCO entity generator. (for persistence ignorance, and decoupling entities from DAL).Business layer that contains a façade for each related group of business functions, the façade will be aware of and using DAL layer. And in each function, it will initiate context and uses different entities to carry out specific job (i.e. function).UI layer that only calls the business layer façade classes. With no awareness of DAL, but it will be aware of entities (i.e. using entities DLL), as the business layer will return results basically as entity collections.
I want to know what you think about this architecture.
I also read about an architecture that uses repository and unit of work patterns, but what I understand that context object is already implementing a UOF pattern, and also object sets are implementing repository pattern (correct me if I'm wrong), so the only advantage of using additional abstraction over them is to make the business layer communicates to my classes, not EF classes, and this is good only if the DAL strategy might change (i.e. by using another tool other than EF, which is not my plan).
