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?
We have an ASP.NET MVC site that uses Entity Framework abstractions with Repository and UnitOfWork patterns. What I'm wondering is how others have implemented navigation of complex object graphs with these patterns. Let me give an example from one of our controllers:
[code]....
It's a registration process and pretty much everything hangs off the POCO class Person. In this case we're caching the person through the registration process. I've now started implementing the latter part of the registration process which requires access to data deeper in the object graph. Specifically DPA data which hangs off Legal inside Country.
The code above is just mapping out the model information into a simpler format for the ViewModel. My question is do you consider this fairly deep navigation of the graph good practice or would you abstract out the retrieval of the objects further down the graph into repositories?
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 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 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 am using C# in ASP.NET 2.0
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 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'm working on adding an HtmlHelper for pagination, but I am unsure where the proper and/or most beneficial place to put certain parts of the pagination code from a performance and maintainability standpoint.
I am unsure if the Skip(), Take() and Count() portions of Linq to SQL data manipulation should live within the repository or the controller.
I am also unsure if their order and where they are used affects performance in any way.
If they live within the repository from my understanding this is how it would work:
1. I would pass the pageIndex and pageSize as arguments to the repository's method that grabs the data from the database.
2. Then grab the full data set from the database.
3. Then store the count of TotalItems of that full data set in a variable.
4. Then apply the Skip() and Take() so the data set retains only the page I need.
5. Display the partial data set as a single page in the view.
If they live in the controller from my understanding this is how it would work:
1. I would grab the full data set from the repository and store it into a variable inside of the controller.
2. Then get the count of TotalItems for the full data set.
3. Then apply the Skip() and Take() so the data set retains only the page I need.
4. Display the partial data set as a single page in the view.
Inside the controller (I realize I will incorrectly get the page count here and not TotalItems):
[code]....
i am using EF4 and StructureMap in an asp.net web application. I am using the repository/unit of work patterns as detailed in this post. In the code, there is a line that delegates the setup of an ObjectContext in global.asax.
EntityUnitOfWorkFactory.SetObjectContext(() => new MyObjectContext());
On the web page code-behind, you can create a generic repository interface like so ...
IRepository<MyPocoObject> ds = ObjectFactory.GetInstance<IRepository<MyPocoObject>>();
My question is what is a good approach to refactoring this code so that I can use more than one ObjectContext and differentiate between them in the code-behind? Basically i have two databases/entity models in my application and need to query them both on the same page.
I am trying to understand the fundamental differences between the Provider Model and Repository Pattern.
I have used the Provider Model in many many situations and am confident with it when designing applications. However, the more examples I encounter on the internet and asp.net evolution I keep coming across "Repository" Interfaces for classes that look like a Provider Model.
I have dug around a bit but all I can see is that they kinda do the same thing, or closely overlap by enforcing an inheriting class to adhere to a "contract" of implemented / abstracted methods etc...is there more to it?
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. Can we use Html Helpers/Repositary Pattern/Ninject in Webforms?
View 1 RepliesWe are going to develop content Management System in ASP.net. what is the good design pattern do we need to follow in order to have good design.
View 2 RepliesJust 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..
[URL]
What would be better ?
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..
[URL]
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).
how to complete my implementation of the Repository pattern in an ASP.NET web application.
At the moment, I have a repository interface per domain class defining methods for e.g. loading and saving instances of that class.
Each repository interface is implemented by a class which does the NHibernate stuff. Castle Windsor sorts out the DI of the class into the interface according to web.config. An example of an implemented class is provided below:
[code].....
As pointed out in a previous thread, the repository class needs to accept an unit of work container (i.e. ISession) rather than instantiating it in every method.
I anticipate that the unit of work container will be created by each aspx page when needed (for example, in a property).
How do I then specify that this unit of work container instance is to be passed into the constructor of StoredWillRepository when Windsor is creating it for me?
i want to ask question i have simple regular expression pattern like "[ABC]" when i add it to me class
[Code]....
it is working good when i add A , B Or C as i need.but if i copy this pattern and paste it in my regular expression validator control it is not working
I want do Fancybox work without a click. I want fancybox work as a alert in onload.
View 2 RepliesDoes anyone have a working pattern for converting a GET-POST-GET pattern to asny?
I'm encountering the following issues:
1. You cannot mix Sync and Async action methods SubmitForm(), SubmitFormAsync(bool? confirm), SubmitFormCompleted() ... (because the resolver gets all confused ... it doesn't use the HTTP verb to decide who to target. BTW: I think that's poor design, or a bug)
2. Renaming the get method name to something else eg: SubmitFormConfirmation(), SubmitFormAsync(bool? confirm), SubmitFormCompleted() would be very awkward if it works ... because you have to doctor the <form markup to specify an action name.
3. You cannot give them all async names SubmitFormAsync(), SubmitFormAsync(bool? confirm), submitFormCompleted(), because the call just keeps malfunctioning. It sometime even behaves as if you are requesting a delete of something.
Can someone give an insight from an actually working sample.
I got a a problem when using ToolkitScriptManager on masterPage with other webForm in SUbDirectory. Everytime I run other webform in the SubDirectory there was an Error "The ScriptManager must appear before any controls that need it". Then I added ToolkitScriptManager to that page I got another Error "Only one instance of a ScriptManager can be added to the page". hmmmm then I removed the ToolkitScriptManager from the MasterPage, It's worked for that page.
on that SubDirectory I had a webConfig file.
<?xml version="1.0"?>
<configuration>
<location path="MyPage.aspx">
<system.web>
[Code]....
Now that the next version of ASP.NET MVC is being prototyped and previewed (ASP.NET MVC 3 Preview 1 came out a couple of weeks ago), I wonder if we should call the attention of the Core Dev team (S Hanselman, Phil Haack and all) to this "feature."there a easy/non tacky way of associating subdomains → areas?Something like:
[URL]Also, whats the best accepted design pattern in implementing PRG pattern in ASP.NET MVC? I guess it should also get some official loving in MVC 3.
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 have 2 repository that I'm trying to use in the same controller and cant find out how
This is what I'm tried :
[Code]....
for the first one it was working(VortRepository but I cant add the second )
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?