Architecture :: Difference Between Repository And Table Data Gateway
Apr 1, 2010what is the difference between these two patterns?
View 1 Replieswhat is the difference between these two patterns?
View 1 RepliesI 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 want to use payment gateway in my asp.net site.so i want to know the difference between WEB payment gateway and WAP payment gateway.
Both are same or we have to buy them differently.....
i want the difference because i will also create wap site to run on mobile.
integrate payment gateway in my webapplication. I don't have any idea on that.I want to get the payment through debit card, credit card, internet banking too..
View 3 RepliesI 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'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..
[URL]
What would be better ?
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 want to know that What are the factors if we use methods on each .cs page for connection and executing query on each aspx code behind page rather then using BAL .
How our application get affected in terms of performance and speed or other way?
when we put our website on server after publish/compile in general approach (using query in C# code behind) rathor than using stored procedures?
then which logic is better and why ?
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.
[code]....
As per my understanding regarding N-Tier and SOA architecture.
N-Tier
N-Tier means dividing application into layers, Example I am developing application in asp.net and I pushed total DB Layer to WCF then it is called N-tier.[Tightly coupled]
SOA[Loosely coupled]
As per my understanding regarding SOA its very generic term and how well we going to loosely couple our architecture then its called SOA. Best example for SOA services - Stock feeds/ weather feeds.
My conclusion:
Even though if we develop application using WCF it does not mean its SOA if it is tightly couple with single client/ or .net applications only can understand about services.
Can you help me in understanding of SOA VS N-Tier.
i create 3folder in solution explorar,model view ,conroller in view i inclde .aspx formsin model class related to data base and in controller properties .so am i follwing mvc architacture .so what is diffrence b/w mvc architacture and mvc framework
View 1 Replieswhats is the difference three tier and three layer architecture. I need three tier architecture which is fulfill the object oriented requirement. and database change flexibility.
View 4 RepliesI have a site where users can save images together with a couple of info fields about the image. The images are stored as binary data in the same table as the rest of the image info. So far pretty standard.
Now, the users should be able to upload a document, describing the image in more detail, along with the rest of the image and its' info.
Size ~2MB per document.
My question is: Should I store this document (binary data) in the same table as the rest of the images or should I create a new table holding only the documents. There would of course be an id reference in the image table to the document in the document table.
I have a search function joining a couple of tables, including the image table, when searching for images. I need to know if there's a difference in efficiency between these two solutions.
I always fetch the document data separately but if I don't win anything in having the documents in a separate table I'll just put it with the rest of the image info.
I'm asking this since I don't really know how SQL Server handle tables when joing and searching in them.
I have about 10´000 users with a maximum of 10 images per user. (ASP.NET - SQL Server)
(I'm not asking if I should store documents in the database, but how ;)
Example:
columns in imageTable - id, title, dateAdded, image (binary data), document (binary data)
Searching for items from a specific user I would join the userTable and the imageTable and select title where image id equals user id.
So, will there be any difference in the performance if the document is in the imageTable or in an own table?
I have almost 100 website that will update in a condition, I have a winzip archive that contains the files that replaces those websites. I want to know that
I can extract that files in a folder and then copy them to all 100 websites folders
I can extract the archive directly to 100 websites folders
which one is better in performance and less prone to errors
What is the difference between hash table and index table? can any one explain me briefly. Also send me the hashing techniques.
View 2 RepliesI have- empId - PK, CurrentUserId in one table,mpId- FK in other table.now i want to get empId of related currentUserId ,and want to add empId in other table having FK,using Repository,what will be in create method?
View 4 RepliesI am looking to use a controller to accept post data from an external provider (text message replies from SMS API). Here is a sample of the data that will be posted:
[Code]....
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 should create a table in this way
A B C(A-B)
50 100 -50
100 50 50
100 100 0
My Procedure is here
[Code]....
[Code]....
[Code]....
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.