I've not yet found a clear answer to this and to clarify:
With nHibernate and SQL server are you expected to disregard or migrate your business logic stored in your stored procedures, views and triggers into HQL or application code?
NHibernate is an O/R mapper which is very suited for applications that are build using a 'domain driven' methodology.
In such applications, the domain model is an expressive object oriented model of the business. This means that the 'model' contains all (or most of) the business logic.
In such cases, I see very little (if any) situations where you would put business logic into stored procedures.
Well, leaving aside all details: yes.
NH is an Object-relational mapper, and is intended to be used with an architectural style called 'Domain-Driven Design'. An important aspect of it is that it completely disregards the database for anything other than saving and loading data - this concept is called Persistence Ignorance, and its motto is: There is no database.
From this point of view, having business logic living in stored procedures or some other db object is not only discouraged, but it would clearly be a severe code smell.
If you follow the preferred Domain-Driven Design methodology, there will be just no opportunity to put business logic into the db - simply because there isn't any db around at the time of constructing your business layer...
Related
I created for a project a single class, that contains all access code to the database.
Is this a good practice , under the assumption that this class doesn't contain any logic, or should i use several classes? If yes, how should i partition my code? I use C# .Net.
Actually Under the concept of MVC framework, it is a good practice to create a different class for database access, seperate class for logic and seperate class for your views.
You are doing good if you are writing a seperate class for database access under the assumption that it does not contain any logic.
In Agile Developement there is a term named as Database Encapsulation Layers.
A database encapsulation layer hides the implementation details of your database, including their physical schemas, from your business code. In effect this layer provides your business objects with persistence services – the ability to read data from, write data to, and delete data from – data sources. Ideally your business objects should know nothing about how they are persisted, it just happens. Database encapsulation layers aren’t magic and they aren’t academic theories; database encapsulation layers are commonly used practice by both large and small applications as well as in both simple and complex applications. Database encapsulation layers are an important technique that every agile software developer should be aware of and be prepared to use.
An effective database encapsulation layer will provide several benefits:
-> It reduces the coupling between your object schema and your data schema, increasing your ability to evolve either one.
-> It implements all database-related code in one place.
-> It simplifies the job of application programmers.
-> It allows application programmers to focus on the business problem and Agile DBA(s) can focus on the database.
-> It gives you a common place to implement data-oriented business rules and logic.
-> It takes advantage of specific database features, increasing application performance.
Hope this helps.
If your database is quite small, say, only a couple of tables, you could write all your queries in one class. otherwise I would suggest that per Entity/Table one class. for example, StudentDao.class will only focus on the queries to database table "STUDENT", and TeacherDao.class will only contain queries to table "TEACHER". if you are gonna implement a complex business logic, you may want to have a service class, to weave StudentDao and TeacherDao together.
Unless your data access is very simple, probably not.
you probably shouldn't need to write this code yourself. Take a look at some Object Relational Mapping tools. NHibernate is a popular .Net solution. http://en.wikipedia.org/wiki/NHibernate
If you really do want to write it yourself look up design patterns in this area, like the Data Transfer Object pattern. http://martinfowler.com/eaaCatalog/dataTransferObject.html
These are some of the suggestions while accessing database.
1.) Always keep your database access parameters in a properties file. Use a handler to get those data. Because when you change your database then you need not change your code just make a change in the properties file it's enough.
-- So here you need a handler class.
2.) Never create a single class (a god class) which performs all the actions. Disperse your behaviour in to different classes depending on the intent. For example Keep all read behavior in one class, Write behavior in another class ... so on.
3.) You can create a class which deals with connection creations and pooling stuff...
Hope this helps.
I'm a little confused here.
I have my POCO classes created with the entity framework modeled from the datbase.
Obviously, I'd like to use these classes in the client too (and any bookkeeping on them would be nice if I'd like to send them back and re-attach)
I looked through the classes generated for the WCF service reference and it seems a bit verbose to be sending over the internet, but it doesn't look like there's anything risky in there security-wise.
And yet, I can't find anything online about doing this. Am I going down a completely awful path?
Help?
EDIT : I suppose they're technically they're not POCO classes if i had them generated by the EntityFramework from the database; just to clear up any possible confusion.
This is a difficult question to answer without knowing more details about your system, but ultimately whether exposing your EF entities in the WCF service contract is the right path or not is influenced by the scope and requirements of the application you are developing.
Perhaps ask yourself the following questions which will hopefully guide your decision:
Is it likely your relational model and object model will need to diverge? This can be driven by a number of factors, but most commonly reporting requirements may enforce a certain design on your database schema (for performance) that you do not want to reflect in your application object model. Using the DB generated EF entities throughout the application layers can bind you to this database design
Are you concerned that changes to your database schema may require your clients to regenerate their service references? Again, using the EF entities throughout your application tiers means any changes implemented in your DB schema (whether of concern to the client or not) may bubble up to the service interface, potentially breaking client compatability with that interface
Is performance a concern? As you mentioned, the generated classes are verbose. You are likely to be transporting unnecessary baggage across the wire, which could be optimized.
Are you concerned about exposing the implementation details of your database schema and persistence mechanism on the wire and to your clients? Given you have generated the model from the database there are likely to be properties that expose information about your schema and persistence mechanism that are redundant from a client's perspective.
In summary there may be a limited number of cases where exposing the EF entities may be acceptable but typically I would design for change and implement some sort of pattern where you map your EF entities to light-weight "persistence-ignorant" POCOs at your repository layer. EF 4.0 does provide the ability to code up a context that returns POCOs, but on my current project we use the codegen'd context and then use automapper to map the EF entities to our data contracts. Outside of the repository layer nothing is aware of the EF entities and I feel this allows for a more maintainable and robust design.
I have several objects, like products, order, etc. When I get information from my database I take a row and create one of the types of objects. I then work with that object created. I read this is called a factory.
Is there some advantage to doing this? Especially in a loosely typed language like PHP?
Thanks
edit: is this where I get database agnosticity? Is this what an ORM essentially does?
By creating your objects from the database queries, you are defining the mapping between your objects and the relational database. This is exactly what ORM software does.
By doing so and ensuring that your objects never directly access the database, but instead use your database-access functions/objects, you are protecting your code from changes in two ways:
Changes to your database schema will not ripple through your code. Instead, the code changes will be located only in your database access objects.
You can switch to a different DBMS by implementing a new database layer that follows the same interface as the original. Your other objects will not require changes.
I guess in that sense, you gain some database-agnosticity, but you'll probably be better off using a database library that provides that agnosticity out of the box.
In my opinion, the advantage is you are working with objects and gain all of the advantages that an object-oriented language offers. You can then read the domain logic at a higher level (in terms of the objects you have defined) without sifting through database queries. Writing the ORM yourself can be tough, but there are tools out there that help with that.
This is the route I normally take, but I don't do any PHP development, so I can't say how well it applies to that language.
What you're describing is an implementation of a Data Access Layer - it doesn't sound like an example of the Factory Method pattern, nor the Abstract Factory pattern.
Yes, ORMs bridge the gap from objects to relational databases, and can serve as your Data Access Layer. Bear in mind, any ORM you use has certain pros/cons/limitations. Depending on your experience and requirements, writing your own data access layer is sometimes a good idea; don't feel like you HAVE to use a 3rd-party ORM.
Yes, a good data access layer makes it easy to swap out your storage mechanism (different database, XML, flat files, whatever) without changing your business logic, UI, or other code.
Regardless of loose-typed or strong-typed languages, if you're working in an OO language, it will be much easier to write code using data objects (provided by an ORM or homegrown data access layer). I'm sure it's possible to write a system with no data access layer, where your business layer works directly with the database. But it will likely be more challenging to implement and maintain.
...What is it called?
More elaborate: For my application I created a nice business model to work with as in-memory objects. It's storage and view agnostic. Now, for the storage layer, there's a database: I'll construct SQL queries (the fewer the better) that selects/joins etc. all data I need from the relevant tables. A kind of "middle layer" takes the query(s) result and constructs business objects with all relations.
Questions: What do you call this approach? What are the best practices?
This takes place in a .NET C# project but that's not relevant to this design question.
(I found question 441532 to be very similar but I'm interested in more design input)
Note: I do not take the ORM approach that relies on tools that do this automatically because the application requires only selected data from a relatively large database.
I think it's called ORM, or object-relational mapping.
NHibernate is one example of just such a thing.
It's generally called DDD - Domain Driven Design.
https://stackoverflow.com/questions/tagged/ddd
https://stackoverflow.com/questions/tagged/domain-driven-design
There are different ORM tools. Linq to SQL do a 1:1, which is not what you want.
What you're talking about overlaps with Domain Driven Design, where your design is driven by the domain, not the Database.
In this case, if you are using a relational Database you still need an ORM, and ORMs like Entity Framework and NHibernate allow you to flexibly "map" your entities to your database in any way you want, in a way that, if your Database needs to change for whatever reason, or you Entities have to change, for whatever reason, all you need to change is the middle "mapping" layer.
take a look at fluent nhibernate
I want to know what is best practice for using db views, db tables, stored proc. and objects in tables... Which of these is more flexible and why, can You explain?
Each tool has its uses. Your choices will depend on the nature of the application, and its security, performance, and agility requirements.
Nowadays many programmers use Data Access Layers (DALs) for this sort of thing. Many DALs allow you to specify views and stored procedures to call. But you can also run queries against the tables directly, without the need for stored procedures or views.
Unless you are using an object database, you will be dealing with tables rather than objects. Most applications nowadays use table-based database systems, because they are so common, and you can use DALs to manage the object-relational impedance mismatch.
Stored procedures are used when high-performance is needed, and programmatic things need to be accomplished on the database itself (the addition of a timestamp value perhaps, or the addition/subtraction of child records). A good DAL will provide high performance without necessarily requiring the use of stored procedures.
Views are used to manage the interface between the database and the consumer of the data. In particular, the data can be filtered for security purposes. In large database scenarios, a DBA designs and creates the tables, and manages the views and stored procedures that the user is allows to use to access the data.
If you are looking for ultimate flexibility, most of what you need to do can be accomplished in the DAL, without the need for views or stored procedures. But again, it depends on what your application's requirements are. I would say that the larger your application and user base is, the more likely you are to use views and stored procedures in your application.
I would say that, for the most part, stored procedures are a relic of the '90s:
completely database-dependent
bad language choice for general purpose programming, regardless if it's plpgsql, t-sql or something else
hard to debug
low code scalability, a problem shared with any procedural programming language
code versioning issues
That's not to say that they (like triggers, views and rules) don't have anything to give: large scale reporting and data aggregation is one example of tasks at which they handle fairly well. For the rest, logic is better placed in the business logic layer (a service, domain entities...whatever) where a variety of tools and more advanced programming paradigms are available.
Ditto for views and triggers.
In e.g. a Java environment, JPA does much better 90+% of the time:
learn one query language and apply it to any database
the business logic is more focused, in one place in the application, the BLL
the code is easier to read and write and it's easier to find people who understand it
it's possible to express logic spanning multiple databases in a single unit of code
...and the list goes on.