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
Related
I am currently developing a Windows form application, that I plan to run on a cloud setup, the application will calculate new data, update within the database and act as sort of control panel for a live data feed RestFul API that I wish to create using ASP.NET MVC 5 Web API.
I am wondering is it viable to connect these 2 separate applications to a single database? It is unlikely that I'd have database entry clash issues as each application has a separate task of reading or writing data for certain tables.
If viable would that mean every-time i make table changes I'd have to update both Entity Framework database models? (Not a major chore).
Is there a better solution to this? Should I scrap the idea of running a Windows Form application to control certain elements of the backend of the public API?
What would be the future issues with designing something like this, if any?
So you have a bunch of options there, assuming you have a layered architecture:
Share your DB, DAL and also Business Layer
Extend your WEB API and utilize it in your WinForms
Reuse DAL only (not the best approach, as business systems are not only data, but also - behavior - which resides in Business Layer)
Share the DB only - this is the worst option, with numerous drawbacks
See options 1 and 2 on an image:
Create a Data access layer, as a seperate component.
like a DAL.dll
Each application has a Logic layer, where "whatever you do" is handled.
Each layer, now uses a sort of Interfacelayer, that will translate objects from either layer of your applications, to the objects of the DAL.
When you change the DB now - you merely have to update the interface layer.
(Of course if you are adding more features, you will have to update all layers, but that isn't really any different.
I suggest this appoach, as it will make your debugging task much easier. And the slight extra code overhead won't affect performance, unless you have a massive communication requirement.
If you want more specifics, I would need examples of a classes from either program, and your SQL table design.
But there is nothing wrong with your approach.
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
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?
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.
FYI, I'm working on my first MVC web application using MVC 3 and Razor with C#, and .NET3.5/4.0, and I'm looking for the "best pratice" approach for using existing web services in an MVC 3 application. From what I have figured out so far it looks like all I need to do is the following. Include a reference to the existing web service in the MVC project, create a Model for the data I desire to use in the application, create a Controller that makes the web service call that then fills an object created from the Model (reading about AutoMapper to see how this helps in that process), and then create a View to display the data that was translated into the MVC view model.
The part that I'm having questions about is what is the best way to retrieve and create/update the data from the web service. Maybe I'm over complicating this but it seems like I'm missing something.
Do I need to create a "Domain Model" that maps to the data retrieved from the web service and then create "View Models" that map to the domain model, and then use the View Models within the MVC 3 application?
Basically I'm looking for input on how best to use existing web services as my data access layer.
On your data access layer you would open the connection, get the raw data and then close it. Identically to how you would get data from your database. You would then convert this raw data to your business layer (domain model) via a data adapter. Then any top level applications, such as your MVC3 website, will convert this domain model into an approriate view model, along with any other data for rendering, again through a data adapter.
The main argument for doing it this way is that the service is now accessible to any top tier application that requires it. It is also makes logical sense to put any sort of data retrieval methods in your data access layer, since that's logically what the data access layer is designed to do.
There is always the temptation to simply access the service from your controller, but separation of concerns might suggest this is a bad way to structure your code. You should encapsulate the service as a domain/business layer service for your applications.
So in short, you don't need to, but best practice suggests you should. It can feel tedious sometimes when there is little or no conversion between layers, but it often helps to stay consistent.
To obey the MVC pattern and its separation of concerns, calling the database must be in the model. And if this web services calls the database somehow, it should be at the Model level.
let the UI talk to the model directly, in case later u needed a webservice to integrate with another system you can create a service which calls that model
And you may want to cache it if its read-only