We are developing an application against a SQL Server 2005 database that uses several schemas for security purposes. The application will be using EF 2 in the .NET 4.0 framework.
What I'm wondering is how those SQL Schemas (Support, Admin, Employee) etc. can/will/should be represented on the EF side. Should I separate the various entities into separate models (edmx files) in the application to reflect the SQL schemas? I'm not as concerned about name conflicts as much as understanding the model more intuitively.
What are the recommendations or best practices in this area?
Thanks!
you could decorate your class with TableAttribute if you are using attribute based mapping.
Generally speaking table in one schema is a different entity than table in another schema, so reflecting that you could group your classes in respective namespaces.
Related
Currently I have a monolithic application with some modules like financial and accounting. This application uses a single database and the modules are divided into schemas, so when I need to display the data on user interface or in a report I just need to do a simple query with a couple joins.
My question is, in a microservices structure where each module has his own database, how do I retrieve this data getting the same result as if I were in a single database?
When talking about splitting the database in the process of migrating a monolith to Microservices, there are some known patterns like:
The shared database
Database view
Database wrapping service
Database as a service
Seems the database view or the database as a service could be a candidate in this case, but of course no one better than you can decide which one is viable in your project.
I highly recommend you to have a look at chapter 4 of "Monolith to Microservices" by Sam Newman.
I am working on a project having a large scale database with several stored procedures and I need to use the data in SharePoint 2013, the database is in SQL Server 2008 R2
According to my understanding I have two options:
1) is to create a Web service, using entity framework to interact with the database and most probably will use WebAPI. My logic will be in Stored procedures or DAL layer.
2) Secondly, I did a little research and got to know about the Business connectivity services provided by the SharePoint 2010/2013 as I am working with 2013 so I will be using visual studio 2012. Now learning more about the BCS I understood that I can map each table as a content type and then somehow define relationship. Anwyay, implementing BCS is a separate issue which I think I will somehow manage.
My question is how am I going to import/include my stored procedures? and if not stored procedures then where will I write my queries to get the data from the BCS?
Please direct me to right direction. Thank you.
Using a custom BCS connector you implement the way you want to retrieve the data from the DB (directly in C#), so you can query directly the table, or stored procedures.
If you want to try a BCS connector to create an external content type to use in SharePoint, take a look at my blog. My example is related to indexing sql data for the search, but the way it's done in SharePoint is creating an external content type, and this content type is the one that you index. So you'll find useful information on how to create that BCS connector.
I have SQL Server database and would like to use LINQ to Entities and wrap it with WCF layer and expose it to client. (typical N-Tier architecture). ALso would like to have Persistence ignorant option and also would like to have an option ignore certain fields (sensitive information) in database from serializing it to client.
So what would be best approach for using Entity Framework with Persistence Ignorance, Self Tracking with WCF Support. I could find T4 template with either Self Tracking or Persistence Ignorant.. But everything bundled as single package.
Any help in this would be greatly appreciated.
STEs don't allow any projections - you must expose your entities in their exact form. If you want to hide some fields you must abandon STEs and create your own DTOs (data transfer objects) exposing only subset of your entities data. Once you use DTOs you must manually handle all change tracking.
In this moment, I have two web applications(one application is an MVC2 application for the management of my project and the second is an application with web services). Both applications have to deal with the database and have Nhibernate for querying the database. Is this a good pattern?, if not what can i do?
Edit 1
Both applications can write to the database. I have a dll project that handle the database transactions and have de nhibernate instance named "Repositorio". Nevertheless, each application will have a different instance of Repositorio.dll so there is going to be multiple threats to the database, what do i have to do to make both application use the same instance of Repositorio.dll?
The answer depends on whether or not both applications can write to the database.
If one is read-only, I'd say you're safe.
I not, I'd argue that a service-oriented approach would recommend creating a service that provided an interface for both applications and was the sole owner of the database.
"service-oriented" does not mean that the service has to be a distributed component (e.g., SOAP or REST or RPC). If you encapsulate the database access in a component with a well-defined interface you can choose to share the component as a DLL in both applications. Only make it a distributed component if that makes sense for both applications.
That sounds perfectly fine to me even if both applications write to the database. I would simply recommend you create a third project as a class library with all your nHibernate related stuff to avoid writing any redundant code in both projects.
I know its possible to generate the database tables from the domain model. But is there any way of doing things the other way. I have a totally awful database (worst I have ever seen). Its sharded (16 Shards!!), split across multiple postgres databases (all on the same server) with foreign key relations like urn:dbtable:guid.
Its proving a major pain in the ass to migrate using SSIS so I want to use NHibernate, read the data into objects and rewrite to a SQL Server database in blissful data-architectural harmony.
Is there any way to scan the current DB using NH or other and build a domain model and mappings?
Thanks!
NHibernate Mapping Generator
- A simple utility to generate NHibernate mapping files and corresponding domain classes from existing DB tables
It's free.