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.
When I first heard about ASP.NET MVC, I was thinking that would mean applications with three parts: model, view, and controller.
Then I read NerdDinner and learned the ways of repositories and view-models. Next, I read this tutorial and soon became sold on the virtues of a service layer. Finally, I read the Fluent Validation documentation, and I'll be darned if I didn't end up writing a bunch of validators.
Tonight, I took a step back and thought about what had become of my project. It seems to have become the victim of the design pattern equivalent of "feature creep". Somehow I'd gone from Model-View-Controller to Model-Repository-Service-Validator-View-ViewModel-Controller. You want loosely coupled and DRY? We got your loosely coupled and DRY right here! But I'm wondering if this could be a case of too much of a good thing.
Am I right to be concerned? Or is this actually not as crazy as it sounds? On one hand, it seems crazy to have so many layers. On the other hand, every layer has a clearly defined purpose that makes sense to me. Have your MVC applications turned into MRSVVVMC apps too? If not, what do they look like? Where's that right balance?
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..
can't connect to sql 2005 express sp1 and vs is also sp1. 2) Which my guess is because of the database connection not being able... design view is not able to pull in the application for design, it's as if there is no theme and css just white background and black print.
I installed Rad Controls. Using that controls, I designed my application pages. At design time, the design is not visible. It shows the following error:
RadTabStrip1Failed to create designer 'Telerik.Web.UI.RadTabStrip, Telerik.Web.UI, Version=2010.1.415.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4'
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'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.
I'm about to design my Web service API, most of the functions of my API is basically very simular to my web application. Now the question is, should I create 1 single method and reuse them for both the web application and the web service api? (This seems to be the logical solution, however its very complicated; it's much easier to duplicate the method used by the web application, and keep both separate, ie one method for the web application and one method for the web service.)
1) REUSE: one main method and reuse them for both web application and web service application (I like this but it's complicated)
WebAppMethodX --uses--> COMMONFUNCTIONMETHOD_X APIMethodX ---uses----> COMMONFUNCTIONMETHOD_X ie Commonfunctionmethod_x contains reusable set of common features PRO: less code, less maintenance, less bugs. CON: very complicated
2) DUPLICATE: two methods, one method for the web application and one method for the web service.
WebAppMethodX APIMethodX PRO: simple CON: duplication = more code, more maintenance, more bugs!
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 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 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'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 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.
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.
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?
