Architecture :: EF4 With Repository And Unit Of Work Patterns?
Sep 26, 2010
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).
I read some article about unitOfwork and repository but i'm still confused about how they interact, and how to use them in the right way.
I'm using an addressbook project to practise on patterns (even if , likely, patterns are not usefull) without any ORM framework for persistence.
My domain objects are (at now) : AddressBook (acts as an application controller), Contact (contains information about each contact in the address book), ContactGroup (mantain collections of contact).
Should i have to use distinct repository object for contact ad contactgroup?
I thought to use a UnitOfWork for the operation about the adding/removing contact to group : the user can add existing contact to a group, create a new contact while adding it to the group or remove contact from group.
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..
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..
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?
Does anybody knows good, short and slim tutorials (not here ), which describe actual/modern web-application architectures / patterns (especially for ASP.NET based (classic and MVC) applications (maybe also with embedded Silverlight components) ? How would you you design today an ASP.NET application which uses different datasources (databases, services,...) ? Background: I has been away a couple of years writing web applications, and I want to start now again. So at the moment I am a little bit unsure, how to take off and find the right starting point.
I am having troubles understanding the purposes of using Factory pattern, I understand Factory pattern uses Factory class that has methods to return concrete objects. But why don't I simply use new opertor to create concrete objects? Some articles suggest Factory methods could return objects of different concreate classes, I can do the same thing by using switch statement.
Also are there classes in .Net framework already implementing Factory pattern? I think that will give me a better ideas why it is useful.
Our site is expected to allow the user to do whatever they want from a number of different places. Except, that doing whatever they want really means firing off mini sequences of pages they must vist (or possibly abort from to go off to another task) before returning to their starting point. So, at any given time, the user has a list of pages they are allowed to go to, a list of pages they must go to in order to complete their task, and some end point they must eventually return to, all of which are constantly changing.
As an example, a user may choose to edit an order they placed, at which point they must step through a series of pages to edit the order. These pages to edit an order may be different based on the type of order they are editing, and they must return to whatever place they were at when they decided to start editing the order. They may also have certain options of other pages to visit during their order editing process.
I really need a good way to handle this for a large number of different scenarios, and allow it to be easily changed. Right now we are doing things like setting session variables when a user chooses an action and checking them within the page on button handlers to see what they are allowed to do or where they are allowed to go. I'd love to be able to abstract this out into something that can be easily examined in one place, or even data driven, and have some sort of navigation controller pointing them to the pages they can or must go.
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?
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.
the more i read about pattern the more i get confused!
In particular i'm trying to get the relationship between Registry and Repository.
Is it correct to say that a possible implementation of a Registry uses a Factory to return an appropriate Repository which, in turns, uses an underline DataMapper to performe the CRUD operations against a database?
If no, which kind of relationship exists between repository and registry ?
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?
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'm using the mock framework to unit test some methods. I came across some methods that use delegates. I did not find a way to setup these delegates to return the objects that I want. The mock framework does not support it as far as I know. Is this supported in other mock frameworks like nMock?
I am using unity, entity framework 4 with POCO classes, repository pattern for DAL and services for Business Logic control.I also want to use Unit of Work so I can package together CRUD operations which I perform on different services and then commit them all together.My question is what would be the proper way to inject the Unit Of Work mechanism into my application using Microsoft Unity?I understand that I can put the IUnitOfWork together with the repository on the constructor of the proper service and then if Unity mapping is specified it would auto initiate the proper instances, but this way I do not pass the global unit of work but rather create a new instance on each level, which can't be a smart way to do it (actually the repository is initiated even before the service).
private IUnitOfWork _uow; /// <summary> /// Returns the active object context /// </summary> private ObjectContext ObjectContext [code]...
I am designing a web application and have separate layers for UI, BAL, DAL and DB, while using custom business objects and collections. The app will be used by over 10,000 + registered used and it becoming more complex as I add new functionality such as inline editing and batch processing of collections with transactions ... which has me up late at night trying to design the best approach for this ...In some UI web forms, I bind say 3 controls to 3 different collections. The UI calls the BAL classes for the required collections, then binds the collection returned. So for each collection I want, a db connection is opened and closed. As I understand database connectivity adds overhead so Is there anyway I can design this so 1 database connection is created for a unit of work in a 3-tier or n-tier architecture?
Recently for a class to implement unit test for one of its private methods I used PrivateObject by creating private accessor instead of refelection, to which i received a code review comment as below
"My main concern with Private Object is the use of object[] in constructor. It replaces strong typing enforced by compiler with JavaScript-style run-time error detection.Consequently , personally, I would not recommend it."
Comments above confused me beacuse as per my understanding reflection also needs the object[] to invoke any method.
I'm in the middle-end of written a big website that work a lot with the db. In every call a page runs 5-12 different queries.What I did was build an execute class that uses MySqlConnector API, which get string that represent the sql and the parameters and then just execute the query and return DataTable. In addition to that I have a class that hold all the function that call the execute class functions. For example in the class I have getAllProducts, getOldestProducts etc... and in each and every one of them theres sql statements.
Recently I watch the LINQ video series(How Do I with LINQ - on this site) and it looked good.As I sees it my way is very good because it just open connection execute the sql get the result and close the connection.The question is what is the best performance wise way to build this site? Is it my way that I use all along? Is it using LINQ? Or working with DataSet/TypedDataSet is the preferred way?
I'm using VSTS 2K8 and I've set up a Unit Test Project. In it, I have a test class with a method that does a simple assertion. I'm using an Excel 2007 spreadsheet as my data source.
My test method looks like this:
[Code]....
As indicated in the method decoration attributes, my Excel spreadsheet is on my local C:/ Drive. In it, the sheet where all of my data is located is named "Sheet1".I've copied the Excel spreadsheet into my project and I've set its Build Action = "Content" and I've set its Copy to Output Directory = "Copy if Newer".
When trying to run this simple unit test, I receive the following error:
The unit test adapter failed to connect to the data source or to read the data. For more information on troubleshooting this error, see "Troubleshooting Data-Driven Unit Tests" (http://go.microsoft.com/fwlink/?LinkId=62412) in the MSDN Library. Error details: ERROR [42S02] [Microsoft][ODBC Excel Driver] The Microsoft Office Access database engine could not find the object 'Sheet1'. Make sure the object exists and that you spell its name and the path name correctly.
I've verified that the sheet name is spelled correctly (i.e. Sheet1) and I've verified that my data sources are set correctly.Web searches haven't turned up much at all. [Code]....
