I'm learning MVC. There are plenty of sample codes working with SQL Server. The coder has the database created on the fly from his/her classes, which enables a very clean and rapid development workflow.
I'm working with Oracle DB.
Can I also abstract data from tables, that I already have? I don't need to abstract all columns(i.e. i need only two of 50). I need only read access and wanna use either web service or oracle as input.
You know any sample code, so I can see how can abstract data for web-service or oracle as data source?
You could take a look at Entity Framework. It allows you to abstract your data access code from the underlying database. This really is not MVC specific and you could use it in any .NET application you wish.
As far as web services are concerned I would recommend you designing a data access layer that will be called from your MVC controllers and which would delegate the calls to the underlying web service. An abstraction over this web service would be beneficial if you want to unit test your controllers in isolation.
Related
I'm about to start a project which will require a web site, connected to a web service. The web service will retrieve data from a database, and return it to the website.
My question is about how to properly separate business concerns with data access.
The service can be separated by utilizing the repository pattern. Then in the service calls implementations I can get the required data from the repository in the form of entities, then return it over the wire.
Similarly I can do the same on the website. Use the repository to hide the implementation details of getting the data from the service and serializing it into an entity or entities.
However, my main issue with this approach is that both the service and the website will both have definitions for their entities. Is there a pattern I can use that will allow me to define these entities once, or is this architecture way off from what is common / best practice.
I should mention that the technologies I'm using are asp.net with c# and I'm not using an entity framework.
Create a WCF Data Service and a client for it in the very same solution. Visual Studio will enable to use the very same classes and model at client side what you define in the service side.
Bonus: In case you use the concept right, the IQueryable will can be marshalled to client side (not the result), so you can even do ad-hoc queries in client side, (supposing you repository's method returns with IQueryable) just the result will travel in the wire. This will be important for paging scenarios too.
Start reading here
I want to build a generic data access layer targeting any multiple databases i.e. SQL Server, Oracle, DB2, etc, and the tricky part is that I need to also support Web Services, so my datasource can also be a Web Service. Each of the data sources have similar data but the column names are different and the return type(s) are different in the web services as well.
How can i create a generic Data access layer to target any datasource and return a generic object/list to the UI in .NET, C#.
.NET 4.5, C#, Web API, VS 2013 is what i am using.
Please suggest. Any help is greatly appreciated.
cheers
You are making things way too complicated in my opinion. Just create data access components for every data source type you have, and have them return business or domain entities that you define. Use the power of each data source to its fullest instead of trying to make them 'generic'.
Also, why treat a web service as a data source? It's a web service, already abstracted out. Just use it in your application layer and use its entities.
Bottom line: if it's too hard to do, then don't do it and keep it simple.
Also read http://ayende.com/blog/4567/the-false-myth-of-encapsulating-data-access-in-the-dal.
Please bear with me as I am new to MVC and WCF and may be asking the wrong question.
I am trying to write a WCF service and an MVC web application over an existing project that contains entity, data and business layers. The MVC and WCF components would then replace an older web service and WebForms application which worked very diferently and did not use modern practices.
I see the need to generate DTO objects against all Entity objects and was wondering how we can generate them. Through reflection, digging into the DbContext or some other method.
Furthermore, I also want to generate repository partial classes minimizing the need to maintain hand-written code for a large data model.
How do large development teams do this?
Greetings!
I have recently built out a template for one of my clients that includes a lot of new features, not the least of which is EF/WCF RIA.
Deployment time is greatly reduced when I can connect via EF directly to a table. No more CRUD SPROCs for all 50 tables. I've read that EF, by default, doesn't allow for standard SQL Injections, but I am wondering if anyone can provide me with a comprehensive security overview, or at least enough data where I can sit down with the senior DBA/Security guy here, and convince him that writing all of the CRUD SPROC's aren't necessary.
I've read MSDN Security Considerations (Entity Framework), Security for WCF RIA Services, and a slew of other articles, but I thought I'd give SO a try and ask for some real world implementations & hard evidence in terms of security & EF.
Your thoughts are greatly apprecaited
The senior DBA/Security guy here had a lot of questions about how
Your client program never access SQL directly, instead they are calling RIA Service and RIA Service is inside your ASP.NET, which is completely under your control.
You can intercept your ObjectContext by overriding methods like SaveChanges and you can limit your IQueryable in your RIA Services Template classes.
C# or VB.NET code is very easy to read and understand instead of stored procedures.
Maintenance of stored procedure is sure a pain.
RIA Service provides you method templates where you can intercept logic and manipulate and monitor actions taken against database.
The one and the only difference is, your logic of monitoring and manipulation for CRUD executes inside ASP.NET Application Pool in case of WCF RIA Services and in case of Stored Procedure, it executes within your Database server.
In both the cases, your client has no direct access.
EF already validates your data before storing in DB against the model you have created.
Future edition of SQL Server is coming with inbuilt modelling tools which will anyway deprecate stored procedures for CRUD in some way.
I had to deal with this as well. I'm not sure if your situation is the same in the sense you can still use EF with proc function exports. I can't say I did any better but I did educate the DBA person on the WCF RIA security boundaries. Meaning if someone can get authenticated they'll still be able to call the service methods that call the procs. So I guess in my opinion there isn't a huge difference to exposing the entities you need vs exposing service methods that call procs. I was able to get the person to loosen up their restrictions when I showed them how easy it was to do CRUD operations with Linq to entities, which meant less work for them.
I am going to create a new asp.net web service (.NET framework 2.0), the functionality of the web service is to recieve xml input, perform the relevant operation (add/modify/delete) based on the input and return codes which indicates the status of the operation. I am planning to implement two layer architecture (Business layer and database layer) for this web service, could anyone advise whether this is the right structure or any other structure would perform well than this. Basically I need some inputs on designing the web service.
Thanks in advance.
Thanks,
Muru
The Domain Model should express the business logic in a way that is independent on boundary technologies such as WCF or ASP.NET web services.
This adds the requirement of a third layer:
Service
Domain Model
Data access
If you don't make a separate layer for the technology specific interfaces (Service), you might as well just make a single, monolithic application, because you wouldn't be able to reuse the business logic anyway.
While we're at it: use WCF, not ASMX, for web services.
I would write a web service using ASMX because it's easier to get your head around to start with.
Implement DAL by using ADO or LINQ (might be easier option since it does all the mapping for you and it's good to learn something new imo).
How are you going to call a web service? Did you consider how you will return status code? You can look into JavaScript and Ajax so that you can return custom objects to the client, or you could look into SOAP, which is xml based.
Can also recommend a good read - ASP.Net and Ajax: architecting web applications. Might give you a better idea on what options you have.
i always use the same model: service / business layer and a database layer.
When it comes to Visual studio, i have 4 or 5 projects:
1 with the webservice named project.webservice (which ONLY task it is to receive input and give that input to the layer that does the thinking (business layer), so testing is easyly done to the business layer
1 with the service layer named project.service which does the actual work (decide what the operation should be, call the right db methods etc)
1 with the database logic called project.datalayer which could be ADO.Net code or the Entity framework.
1 with the dataclasses called project.model. These classes are the ones returned by the ADO.Net code and used by the service and the webservice project. If i use a entity framework i normally skip this project, because the EF itself gives me dataclasses the EF generates. Sometimes clients don't want to use the EF dataclasses, then i create the project.model project and let the datalayer translate the EF dataclasses to project.model dataclasses
1 with the testproject named project.test
hop this helps,
Michel